But thats referring to $( $) not ${ $}. I think it'd be wrong to put the 
sources in the signature calculation as they are probably already in the 
dependencies, but I don't know if it does or doesn't

----- Original Message -----
From: [email protected]
To: TOM TANNER (BLOOMBERG/ LONDON), [email protected]
At: Sep 20 2012 18:18:09

Tom,

Everything which isn't wrapped in $( $)... from manpage:
The special pseudo-variables*$(*and*$)*may be used to surround parts of 
a command line that may change/without/causing a rebuild--that is, which 
are not included in the signature of target files built with this 
command. All text between*$(*and*$)*will be removed from the command 
line before it is added to file signatures, and the*$(*and*$)*will be 
removed before the command is executed. For example, the command line:

-Bill

On 09/20/2012 12:27 AM, Tom Tanner (BLOOMBERG/ LONDON) wrote:
> The other thing I'm not sure about is if I have a build script that says
>     '$PERL -w ${SOURCES[1]} blah blah blah ${SOURCE.base}'
>
> how much of that gets put into the the signature when it's being calculated.
>
> ----- Original Message -----
> From: [email protected]
> To: TOM TANNER (BLOOMBERG/ LONDON), [email protected]
> At: Sep 19 2012 18:50:19
>
> Tom,
>
> Wouldn't grep'ing your SConstruct/SConscripts find this for you?
>
> -Bill
> On Sep 19, 2012, at 10:00 AM, TOM TANNER (BLOOMBERG/ LONDON) 
> <[email protected]> wrote:
>
>> Due to not really paying attention when I was developing some of my scripts, 
>> I have some command lines that contain names with sort-of-absolute paths. 
>> That is to say its /dev/git/<username>/<projectname>/scripts/somescript
>>
>> Unsurprisiingly, this causes the build not to use the cached version from 
>> /dev/git/<someelses>/<project>/scripts/somescript
>>
>> So I can see how I can fix this by using ${ scriptname $} and making sure 
>> scriptname is referenced as a dependency.
>>
>> However, how can I find out how many places I've done this in? In 
>> particular, is there some why of printing the contents of an action when 
>> you're calculating the signature, so I can scan for ones that have /dev/git 
>> in them?
>>
>> Thanks
>> _______________________________________________
>> Scons-dev mailing list
>> [email protected]
>> http://two.pairlist.net/mailman/listinfo/scons-dev
>


Tom,

Everything which isn't wrapped in $( $)... from manpage:
The special pseudo-variables $( and $) may be used to surround parts of a command line that may change without causing a rebuild--that is, which are not included in the signature of target files built with this command. All text between $( and $) will be removed from the command line before it is added to file signatures, and the $( and $) will be removed before the command is executed. For example, the command line:

-Bill

On 09/20/2012 12:27 AM, Tom Tanner (BLOOMBERG/ LONDON) wrote:
The other thing I'm not sure about is if I have a build script that says
   '$PERL -w ${SOURCES[1]} blah blah blah ${SOURCE.base}'

how much of that gets put into the the signature when it's being calculated.

----- Original Message -----
From: [email protected]
To: TOM TANNER (BLOOMBERG/ LONDON), [email protected]
At: Sep 19 2012 18:50:19

Tom,

Wouldn't grep'ing your SConstruct/SConscripts find this for you?

-Bill
On Sep 19, 2012, at 10:00 AM, TOM TANNER (BLOOMBERG/ LONDON) <[email protected]> wrote:

Due to not really paying attention when I was developing some of my scripts, I have some command lines that contain names with sort-of-absolute paths. That is to say its /dev/git/<username>/<projectname>/scripts/somescript 

Unsurprisiingly, this causes the build not to use the cached version from /dev/git/<someelses>/<project>/scripts/somescript

So I can see how I can fix this by using ${ scriptname $} and making sure scriptname is referenced as a dependency.

However, how can I find out how many places I've done this in? In particular, is there some why of printing the contents of an action when you're calculating the signature, so I can scan for ones that have /dev/git in them?

Thanks
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev


_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev

Reply via email to