[Scons-users] env[X'] and signatures

Tom Tanner (BLOOMBERG/ LONDON) ttanner2 at bloomberg.net
Tue Dec 27 03:23:20 EST 2016


It's something that causes me a certain amount of confusion. I think env.env should actually be a dependency of every build, and really it would also make sense to print the command line as env -i var1=var2 ... cmd

Currently a lot of our commands have something like

MYVAR=${MYVAR} some command

as the command string to (a) ensure a rebuild and (b) make it possible for the user to reproduce the command if it breaks.

Except this doesn't always work, because the build sets up some of its own env. variables which are (a) invisible and (b) aren't the same as the ones the user uses, which causes a certain amount of fun. ANd of course if we need to change one of said variables, it's likely to cause problems.

From: scons-users at scons.org At: 12/26/16 19:43:26
To: scons-users at scons.org
Subject: Re: [Scons-users] env[X'] and signatures

It makes sense that the env should be the same for building and cleaning because the dependency tree is based on the environment. Explicit library dependencies must come from where libraries are listed. The value node is admittedly more obscure. 

Glad you figured it out.

On Dec 26, 2016 1:52 PM, "Fred Wright" <fw at fwright.net> wrote:


On Mon, 26 Dec 2016, William Blevins wrote:

> I do also, but at one point, I got the impression (from him) that this
> changed in SCons. I don't think this was supported implicitly, but it could
> have been supported explicitly by adding the variable to the hash or other.
> This is why I wanted to know the SCons version that "broke" this.

If the details of this behavior are well-documented, it's certainly
escaped me. :-)

I've actually been burned recently in both directions by this issue.  On
the one hand, I found that if LIBPATH isn't set up the same way for
cleaning as it is for building (*), then some targets don't get cleaned.
On the other hand, a Python builder taking an environment variable as an
input doesn't get rerun if the value changes.  To fix that, I added a
Value() node derived from the environment variable, and added it as an
explicit dependency.

* The Configure section is so slow and verbose that it's useful to
suppress most of it when "cleaning or helping".  But one has to be careful
not to perturb the definitions of cleanable targets.

Fred Wright

> On Dec 26, 2016 3:44 AM, "Tom Tanner (BLOOMBERG/ LONDON)" <
> ttanner2 at bloomberg.net> wrote:
>
> > I think he's talking the situation where you set env.env['MYVAR'], which
> > means for something like this
> >
> > env.env['MYVAR'] = 'Fish'
> > env.Command('some_random_script < $SOURCE > $TARGET', sources, targets)
> >
> > and 'some_random_script' does
> >
> > #!/bin/sh
> > echo $MYVAR
> >
> > and you then change the SConscript file and set env.env['MYVAR'] to
> > 'Chips', it won't cause a rebuild.
[...]

_______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users

         _______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20161227/afee7db8/attachment.html>


More information about the Scons-users mailing list