[Scons-users] Custom environment tools evaluated before Configure contexts?

[Gary Granger]

Ok, thanks Mats and Bill for the feedback.  The discouragement against 
Configure() in tools is noted.  Maybe our problem is that we also use 
tools to setup compile and link dependencies, rather than just for 
finding specific commands.  For example, we have tools for boost, so an 
Environment can add that tool to get the compile construction variables 
to build against that library.  Often that can be satisfied with 
pkg-config, but sometimes we have needed the facilities of Configure() 
to find the right compile-time options. (Fwiw, the tools can also be 
chained, so that one tool, such as for a library built in the source 
tree, can in turn require other tools.)

I had not realized that Configure() might sometimes work on a copy. 
Either way, we tend to follow the second suggestion: clone an 
environment before calling Configure() on it, then copy out the 
necessary variables.

I think this "composition of configuration" for construction 
Environments through tools is really a powerful and elegant aspect of 
SCons.  But I suppose we have to be careful against carrying it too 
far... :)

Thanks,
Gary

On 11/7/23 02:26, Bill Deegan wrote:
> Ben,
>
> If having pytest-xdist installed should affect the command line, then 
> you should check for that in the generate() function of your tool
> That would be the more "scons'ian" way to do it.
>
> And in fact this is what SCons does for its own tools when a different 
> tool version/name affects what the correct command lines should be.
> (for example yacc, bison, byacc would want different command lines and 
> in fact generate differently named tools. This is all decided in that 
> tools generate() or some function it calls.)
>
> I'd avoid using configure contexts for such things.
> -Bill
> SCons Project Co-Manager
>
>
> On Tue, Nov 7, 2023 at 3:54 AM Mats Wichmann <mats at wichmann.us> wrote:
>
>     On 11/6/23 12:45, Mats Wichmann wrote:
>
>     ehhh, sent too early, as there one more piece to this thought:
>
>     > On 11/6/23 09:57, Gary Granger wrote:
>     >> We have custom tools that call Configure themselves, which I've
>     >> assumed is a reasonable thing to do.  (Please let me know if
>     not. :)
>     >
>     > It works, as long as you keep some things in mind: it's optional
>     what to
>     > do with the caching of configure checks. If you run with
>     --config=force,
>     > any cached checks are ignored, and as a side effect, the configure
>     > context works off a *copy* of the passed env; otherwise it can
>     modify it
>     > in place.  This is why we often see stanzas like:
>     >
>     > conf = env.Configure()
>     > env = conf.Finish()
>
>     of course, that stanza doesn't work in a called function like your
>     tool's generate(), because you'd only be replacing the local variable
>     that holds the passed argument. So there you'd have to pick things
>     out
>     if you wanted them, to be safe:
>
>     conf_env = conf.Finish
>     env['FOO'] = conf_env.get("FOO", somedefault)
>
>
>
>     _______________________________________________
>     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/20231109/e802ed21/attachment.htm>