modified NOUPDATE ??

folks,

is it possible for a target T1 to depend on a target xxx.dll.a
and yet be NOT affected by time-stamp on the target xxx.dll.a ?

we are in a situation where updating actions of the target xxx.dll.a
may or may NOT really update the target xxx.dll.a

if it ended up so that actions associated with xxx.dll.a did NOT
actually change the contents of xxx.dll.a, is there a way
to NOT rebuild target T1 that depends upon xxx.dll.a ?

the NOUPDATE builtin rule provides some of this functionality.
but the problem with NOUPDATE is that once the target xxx.dll.a gets
built, actions associated with it never get executed. what we wanted
was for the actions to get executed and let actions decide if the
target needs update or not.

i would appreciate any help that you could provide on this.

thanks,
-badari

Re: modified NOUPDATE ??

On Tue, 1 Oct 2002, Badari Kakumani wrote:

>
> folks,
>
> is it possible for a target T1 to depend on a target xxx.dll.a
> and yet be NOT affected by time-stamp on the target xxx.dll.a ?
>
> we are in a situation where updating actions of the target xxx.dll.a
> may or may NOT really update the target xxx.dll.a
>
> if it ended up so that actions associated with xxx.dll.a did NOT
> actually change the contents of xxx.dll.a, is there a way
> to NOT rebuild target T1 that depends upon xxx.dll.a ?
>
> the NOUPDATE builtin rule provides some of this functionality.
> but the problem with NOUPDATE is that once the target xxx.dll.a gets
> built, actions associated with it never get executed. what we wanted
> was for the actions to get executed and let actions decide if the
> target needs update or not.

You certainly mean the actions building xxx.dll.a, not the ones for T1?!
AFAIK there is no jam feature allowing for that. You can perhaps work
around by introducing another target (an actual file) that is touched by
the xxx.dll.a actions when something has changed, but left alone when
everything is still the same. You would make T1 depend on this helper
target (not on xxx.dll.a) and thus cause updates only when needed.

CU, Ingo

Re: modified NOUPDATE ??

Ingo Weinhold writes:
> On Tue, 1 Oct 2002, Badari Kakumani wrote:
> 
> >
> > folks,
> >
> > is it possible for a target T1 to depend on a target xxx.dll.a
> > and yet be NOT affected by time-stamp on the target xxx.dll.a ?
> >
> > we are in a situation where updating actions of the target xxx.dll.a
> > may or may NOT really update the target xxx.dll.a
> >
> > if it ended up so that actions associated with xxx.dll.a did NOT
> > actually change the contents of xxx.dll.a, is there a way
> > to NOT rebuild target T1 that depends upon xxx.dll.a ?
> >
> > the NOUPDATE builtin rule provides some of this functionality.
> > but the problem with NOUPDATE is that once the target xxx.dll.a gets
> > built, actions associated with it never get executed. what we wanted
> > was for the actions to get executed and let actions decide if the
> > target needs update or not.
> 
> You certainly mean the actions building xxx.dll.a, not the ones for T1?!
> AFAIK there is no jam feature allowing for that. You can perhaps work
> around by introducing another target (an actual file) that is touched by
> the xxx.dll.a actions when something has changed, but left alone when
> everything is still the same. You would make T1 depend on this helper
> target (not on xxx.dll.a) and thus cause updates only when needed.

only caveat with this is that when you invoke:

Re: modified NOUPDATE ??

[...]
> > You certainly mean the actions building xxx.dll.a, not the ones for 
> > T1?!
> > AFAIK there is no jam feature allowing for that. You can perhaps 
> > work
> > around by introducing another target (an actual file) that is 
> > touched by
> > the xxx.dll.a actions when something has changed, but left alone 
> > when
> > everything is still the same. You would make T1 depend on this 
> > helper
> > target (not on xxx.dll.a) and thus cause updates only when needed.
> 
> only caveat with this is that when you invoke:
>      'jam -j8 T1'
> it will NOT check to see if xxx.dll.a is outdated and rebuild it.

It's worse, as it wouldn't even work, if don't specify a target (or 
build `all'). First jam analyzes the dependencies and which targets 
need to be updated and thereafter it actually updates the targets. So 
there is no feedback possible at all. Your actions can't influence what 
is updated.
Sorry, I shouldn't reply, when I'm not completely awake. 

> i wanted actions associated with building xxx.dll.a be run
> whenever xxx.dll.a is outdated - only that 
> 	 a) the actions may or may NOT really update xxx.dll.a AND
>          b) T1 should NOT be considered outdated because of xxx.dll.a 
> (though
>             jam figured xxx.dll.a is outdated and invoked

Re: modified NOUPDATE ??

Ingo Weinhold writes:
> [...]
> > > You certainly mean the actions building xxx.dll.a, not the ones for 
> > > T1?!
> > > AFAIK there is no jam feature allowing for that. You can perhaps 
> > > work
> > > around by introducing another target (an actual file) that is 
> > > touched by
> > > the xxx.dll.a actions when something has changed, but left alone 
> > > when
> > > everything is still the same. You would make T1 depend on this 
> > > helper
> > > target (not on xxx.dll.a) and thus cause updates only when needed.
> > 
> > only caveat with this is that when you invoke:
> >      'jam -j8 T1'
> > it will NOT check to see if xxx.dll.a is outdated and rebuild it.
> 
> It's worse, as it wouldn't even work, if don't specify a target (or 
> build `all'). First jam analyzes the dependencies and which targets 
> need to be updated and thereafter it actually updates the targets. So 
> there is no feedback possible at all. Your actions can't influence what 
> is updated.

i am NOT saying actions should influence what is updated.

all i need is a way to tell jam that the target xxx.dll.a will NOT outdate
its parents by using a built-in rule similar to NOUPDATE...

i guess all i need is a rule called NOPARUPDATE and when i invoke:

Re: modified NOUPDATE ??

> i am NOT saying actions should influence what is updated.
>
> all i need is a way to tell jam that the target xxx.dll.a will NOT 
> outdate
> its parents by using a built-in rule similar to NOUPDATE...

Seems that I misunderstood you. You can approximate this behavior 
pretty closely by introducing an intermediate target, say T0. T1 
depends on T0, T0 on xxx.dll.a. T0 is a real file target with NoUpdate 
property. That could look like:

  rule Touch { Depends $(1) : $(2) ; Clean clean : $(1) ; }
  actions Touch { touch $(1) }
  NoUpdate T0 ;
  Touch T0 : xxx.dll.a ;
  RuleToBuildT1 T1 : T0 : xxx.dll.a ...

RuleToBuildT1 could of course as well include the two T0 rule.

> i guess all i need is a rule called NOPARUPDATE and when i invoke:
>    NOPARUPDATE xxx.dll.a
> jam should understand that it should NOT rebuild the parents because
> of xxx.dll.a becoming out-of-date.
> 
> any ideas on implementing such builtin rule?

Adding the rule is simple -- add a flag T_FLAG_NOPARUPDATE in rules.h, 
and duplicate the entry for NoUpdate in load_builtins() in builtins.c 
replacing the name and the flag with yours -- making it work is much 
harder. 

Re: modified NOUPDATE ??

Ingo Weinhold writes:
> > 
> > unfortunately this does not seem to work as per my experiment
> > enclosed. please let me know what you think.
> > 
> > thanks,
> > -badari
> > 
> > # i am simulating that my program called 'proc' depends
> > #    on x.dll.a  and p.c
> > # x.dll.a may or may NOT change based on contents of x.c
> > # so my purpose is 'proc' needs to be rebuilt ONLY when p.c changes.
> > #   change of x.c (and hence x.dll.a) should NOT cause rebuild of 
> > 'proc'
> > ena3 120 % cat noupd
> > 
> > rule Touch { Depends $(1) : $(2) ; 
> > # Clean clean : $(1) ; 
> > }
> > actions Touch { touch $(1) }
> >   DEPENDS proc : int ;
> >   Touch proc : p.c ;
> >   NoUpdate int ;
> >   Touch int : x.dll.a ;
> >   Touch x.dll.a : x.c ;
> > 
> > ena3 119 % l x.c p.c
> > -rw-rw-r--   1 badari   eng             0 Oct  4 12:05 p.c
> > -rw-rw-r--   1 badari   eng             0 Oct  4 12:07 x.c

Handling of whitespace in Windows / directory separator hack

I've been setting up a series of Jamfiles for porting a Win32-only game from a 
Visual Studio build, using the latest Jam checked out from the Public Source 
Depot.

My persistent stumbling block is Jam's handling of white space in directory 
names.  Because I've got VC++ & the Platform SDK in their default locations 
(as do the other programmers on this project), I've got to have Jam handle 
directories with whitespace properly, and I'm not sure whether it can, or 
whether I'm just not doing it correctly.  Either way the docs don't really 
address this.

The most pressing problem I'm facing is that the call to the linker ends up 
looking like this:

link program.exe ... tons of object files ...
"c:/program\lib\advapi32.lib files/microsoft\lib\advapi32.lib 
visual\lib\advapi32.lib studio/vc98/"\lib\advapi32.lib 
"c:/program\lib\libc.lib files/microsoft\lib\libc.lib visual\lib\libc.lib 
studio/vc98/"\lib\libc.lib "c:/program\lib\oldnames.lib 
files/microsoft\lib\oldnames.lib visual\lib\oldnames.lib 
studio/vc98/"\lib\oldnames.lib "c:/program\lib\kernel32.lib 
files/microsoft\lib\kernel32.lib visual\lib\kernel32.lib 
studio/vc98/"\lib\kernel32.lib

Now all I did was to specify MSVCRT="c:\program files\microsoft visual 
studio\vc98" and let Jam handle the call to the linker.  It seems as if its 
"product" variable expansion is causing this problem, but is there any way to 
avoid it?  Can someone at least talk me through what's going on?

Also, the only way I've found to add include directories containing spaces 

GLOBbing and OpenVMS

VMS, dependencies, relative headers