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

[Gary Granger]

We have custom tools that call Configure themselves, which I've assumed 
is a reasonable thing to do.  (Please let me know if not. :)  So for 
example, you could move the Configure context code below into the 
generate() function of the tool which creates the pytest actions.  That 
way the configuration context is part of the tool. If the tool 
configuration is going to be the same for every environment which 
applies that tool, ie, every environment will use the same settings for 
PYTEST_INSTALLED and PYTEST_XDIST_INSTALLED, then those settings can be 
cached in the tool (as module-scope variables) and applied to every 
Environment in the generate() function.  The Configuration context has 
it's own cache, of course, but sometimes module-level caching is helpful 
for configuration settings which only need to be derived once for the 
system.  We do something similar for tool-specific Variables.  The tool 
defines the Variables it offers, then uses those variable settings to 
modify the tool's behavior.

On 11/6/23 07:34, Mats Wichmann wrote:
> On 11/5/23 22:42, Ben Farmer wrote:
>> Hi scons mailing list,
>>
>> I am currently trying to understand the intended usage of the 
>> Configure context vs Environment 'tools'. Here's my scenario: the 
>> codebase I am working on has a bunch of custom 'tools' defined, which 
>> create various "actions" to run, one of which is running some unit 
>> tests via pytest. These are passed to the construction Environment in 
>> it's constructor in the project SConstruct file:
>>
>>      env = Environment(tools=our_custom_tools, ...)
>>
>> However, I would now like to change the behaviour of these tools 
>> depending on the build environment. It's a simple change, I just want 
>> to pass `-n <N>` to pytest to set it to run in parallel if 
>> pytest-xdist is installed. So I figured I would check this somewhere, 
>> then in the custom tool build the pytest Builder action with or 
>> without this -n flag depending on the result. Checking if stuff is 
>> installed seemed like a job for the Configure context, so I made some 
>> custom checks for that following 
>> https://scons.org/doc/production/HTML/scons-man.html#configure_contexts 
>> <https://scons.org/doc/production/HTML/scons-man.html#configure_contexts>, 
>> and do this:
>>
>>      conf = Configure(env, custom_tests={"CheckPytest": check_pytest,
>>                                          "CheckPytestXdist": 
>> check_pytest_xdist})
>>      env["PYTEST_INSTALLED"] = 'true' if conf.CheckPytest() else 'false'
>>      env["PYTEST_XDIST_INSTALLED"] = 'true' if 
>> conf.CheckPytestXdist() else 'false'
>>      conf.Finish()
>>
>> This works totally fine, it checks if `pytest-xdist` is available and 
>> adds some construction variables to communicate this. Unfortunately 
>> it seems like it does this too late. The tools have already been 
>> "built" when Environment was called, so I can't use them to build the 
>> "action" differently depending on the environment
>
> It's  true that for tools specified in the Environment() call (or if 
> none, the default tools list) their generate() method is called as the 
> environment is instantiated. But that doesn't have to be the end of 
> the story.  Here are three avenues you can explore:
>
> * don't specify the tool in the Environment call, but after it is 
> instantiated using env.Tool() - that gives you control over when the 
> initialization happens.
> * if the action is a function, it is passed the environment, so it can 
> make decisions based on settings in construction variables at the time 
> it triggers.
> * generation of the action itself can be deferred by using a generator 
> in the tool's builder. Some more of that topic here:
>
> https://scons.org/doc/production/HTML/scons-user.html#idp105549030489544
>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users