Re: Custom environment tools evaluated before Configure contexts?

Gary,

Ahh.
I've seen similar usage in the past (where tools aren't really tools, but
more about setting up the environment).
I agree that it's a powerful use model.

Probably worth doing something specific for such, and/or documenting a way
to do it.

Any chance we could get you to share your tools in scons-contrib repo?

-Bill

On Thu, Nov 9, 2023 at 11:02 PM Gary Granger <[email protected]> wrote:

> 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 <[email protected]> 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
>> [email protected]
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>
> _______________________________________________
> Scons-users mailing [email protected]://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users