[Scons-users] persistent but local tweaks to a node's environment

[Gabe Black]

On Sun, Aug 1, 2021 at 3:28 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

>
>
> On Sun, Aug 1, 2021 at 2:04 PM Gabe Black <gabe.black at gmail.com> wrote:
>
>>
>>
>> On Sun, Aug 1, 2021 at 12:20 PM Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>>
>>> So at the time you call StaticObject(), for example, do you know what
>>> flags are needed for that  source?
>>>
>>
>> No, I know what *extra* flags are needed for that source, not what those
>> flags will be added to. For instance I know I need to disable a warning
>> because of an unavoidable local false positive, but not to enable debug
>> information, or turn up optimizations.
>>
>
> O.k. That's what I meant (but wasn't as clear as was needed.. ;)
> Where is that info stored? in the Environment() or outside of it?
> Can I access it via something like the following?
> my_object[source_file_name]
>

The information was originally stored in the instances of the Source class,
which is a trivial subclass of SourceFile, defined in the furthest uploaded
tip of my development branch like so:

https://gem5.googlesource.com/public/gem5/+/4fe8793d5f52b2e441fe5495af312d29d9a6d55b/site_scons/gem5_scons/sources.py#191

The classes which records information about the top level target are here:

https://gem5.googlesource.com/public/gem5/+/4fe8793d5f52b2e441fe5495af312d29d9a6d55b/src/SConscript#261

These rely on the SourceList class defined alongside the SourceFile class
above as a way to hold and filter lists of source files based on their tags.

You can see some usage of both the Source() and GTest() (unit test)
constructs here:

https://gem5.googlesource.com/public/gem5/+/4fe8793d5f52b2e441fe5495af312d29d9a6d55b/src/base/SConscript

You can see the simplest example of the fairly uncommon "append" mechanism,
which declares stuff to Append to given variables when a source is built,
here:

https://gem5.googlesource.com/public/gem5/+/4fe8793d5f52b2e441fe5495af312d29d9a6d55b/src/base/stats/SConscript


>
>
>>
>>
>>
>>> Also according to your response above, I would set OBJSUFFIX in the
>>> Environment() which should be per build flavor.
>>>
>>
>> Yes, per my previous email I'm doing that already. as the second to last
>> step, I Clone the main environment and customize it for each flavor, then
>> loop over all the targets (top level and below) for each build flavor.
>>
>
> O.k. so no more work needed for this?
>

The specialization of OBJSUFFIX isn't relevant for individual object files,
but is relevant for the various flavor Environments().

For the code which builds up these Environment()s, see from here to the end
of that SConscript file:

https://gem5.googlesource.com/public/gem5/+/4fe8793d5f52b2e441fe5495af312d29d9a6d55b/src/SConscript#1004

At the very end, you'll see the declare_all() calls on each of the classes
of top level targets. Those may specialize the environment in whatever way
applies to all targets of that class universally, and then passes that
specialized environment down to the "declare()" method defined on
individual instances. That then does any local specialization that's
necessary, resolves what sources to use, and plugs everything into SCons.


>
>
>>
>>
>>>
>>> re a single pass in the SConscripts, if you're not directly calling
>>> SCons methods, but rather building up a "database" of the build which then
>>> gets processed, then it'd be possible to avoid multiple SConscript calls to
>>> each SConscript, however if the logic in those SConscripts doesn't
>>> different things for different variants, it seems like you'd only be adding
>>> more complexity to your "database" of build info.
>>>
>>> Honestly, the further you get from plain SConscripts, the harder it will
>>> be for developers to learn and work on your build system.
>>>
>>
>>
>> Yes, as I've mentioned several times, the idea of this is to get closer
>> to plain SConscripts and remove our extra layers. I'm trying to figure out
>> how to do that.
>>
> Indeed.
> We'll do our best to assist.
>

Appreciated! There is quite a jungle to tame, and eventually google and
grep run out of answers.


>
> Any chance we can get you to join us on our discord server?
> https://discord.gg/pejaFYrD9n
>
> That may speed up this discussion...
>

Yes, I joined there, but I keep unusual hours and may not be very available
when other people are active. I'll poke my head in when I have a block of
time to devote to this next and see if anyone's around.


> _______________________________________________
> 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/20210801/2ca87c3f/attachment-0001.htm>