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

Tue Dec 27 13:33:53 EST 2016

+1

On Dec 27, 2016 1:22 PM, "Bill Deegan" <bill at baddogconsulting.com> wrote:

If every builder depends on all values in env['ENV'], then any change will
rebuild everything.
This is almost never warranted.

Exactly.

I think, ideally, a builder (Action really), would specify what parts of
the Environment() it's sensitive too.

Remember, while many users are only building source code which is fairly
quick, SCons is used in other "build" systems where steps can take
considerable time and resources so extraneous rebuilds are quite costly for
them.

-Bill

On Tue, Dec 27, 2016 at 5:22 AM, Albert Arquer <albert.arquer at gmail.com>
wrote:

> Hi Erling,
>
> I think i started a thread a while ago about this same "issue" and also
> provided a working example, have a look here:
> https://pairlist4.pair.net/pipermail/scons-users/2016-October/005350.html
>
> If this is indeed what you are talking about, I "solved" the issue by
> redefining some scons internal methods to include all the elements in the
> environment into the builder's signature. However I have been forced to use
> pickle instead of dill because of some compatibility issues between scons
> and dill. Using dill would be much better as it's generated dumps are
> sensitive to modifications to the object's class, while pickle is not.
>
> If you are interested in the details of my workaround let me know and I
> can share.
>
> Albert.
>
> El dt, 27 des 2016 a les 13:33 Dirk Bächle <tshortik at gmx.de> va escriure:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi all,
>>
>>
>>
>>
>>
>>
>>
>> On 26.12.2016 20:43, William Blevins
>>
>> wrote:
>>
>>
>>
>>
>>
>>
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> the canonical solution would be to use the "varlist" keyword for the
>>
>> Action class, I guess. Since the Builder wrapper "Command()" doesn't
>>
>> propagate any keywords to the underlying Action() constructor, one
>>
>> has to setup a complete Builder on its own:
>>
>>
>>
>>
>>
>>   import SCons.Action
>>
>>
>>   import SCons.Builder
>>
>>
>>
>>
>>
>>   myAction = SCons.Action.Action('./create.sh',
>>
>> varlist=['MYENVVAR'])
>>
>>
>>   myBuilder = SCons.Builder.Builder(myAction, ...)
>>
>>
>>
>>
>>
>> (untested and from the top of my head). Note how instead of the
>>
>> "create.sh" string an actual Python function may be used too.
>>
>>
>> In the MAN page (search for the "varlist" keyword) there is also the
>>
>> short form described, where all additional arguments (idx > 2)
>>
>> for the Action() constructor are evaluated as "varlist entries":
>>
>>
>>
>>
>>
>>    # Use positional arguments.
>>
>>
>>    a = Action(build_it, '$STRINGIT', ['XXX'])
>>
>>
>>
>>
>>
>>    # Alternatively, use a keyword argument.
>>
>>
>>    a = Action(build_it, varlist=['XXX'])
>>
>>
>>
>>
>>
>> When the signature of the Action gets computed to decide whether a
>>
>> content change has occurred, SCons will subst() all values in the
>>
>> "varlist" and add the result to the cached signature.
>>
>>
>> This should have the desired effect of triggering a rebuild when the
>>
>> content of the environment variable "MYENVVAR" changes.
>>
>>
>>
>>
>>
>> Best regards,
>>
>>
>>
>>
>>
>> Dirk
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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
>
>

_______________________________________________
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/443e132a/attachment-0001.html>