[Scons-dev] First Pillar of Future SCons Tools

[Gary Oberbrunner]

On Tue, Sep 30, 2014 at 10:39 AM, Kenny, Jason L
<jason.l.kenny at intel.com> wrote:
> By this I meant to have a --use-env or something value that would set the Scons environment "ENV" to that of the shell.

There's nothing wrong with this at the user level, but I don't think
it should be hard-wired into the basic tool logic.  After all what is
"the" SCons environment?  In my day job we have four or five main ones
(in a single build), plus a couple of one-offs.  It's important to be
able to configure each one from a known starting point (whether by
cloning or custom high-level tools or whatever), and global options
that affect all tools and/or all environments are dangerous from that
standpoint, as useful as they may be.

I see this as a process of layering.  We should make sure the basic
tool/toolchain infrastructure _can_ support things like a global
--use-env, as well as other models.  Best to build general mechanisms
at the lowest level so high-level add-ons like Parts are both possible
and easy.

I feel the same way about your data-driven approach to tool setup.  I
think at the most basic level, tools must be configurable via
arbitrary code.  Higher layers like Parts should be able to layer in
data-driven tool definitions in whatever mini-language is appropriate
for that type of tool, but based on a common, flexible core.  The
data-driven tool spec will always be more rigid but safer and simpler
than arbitrary configuration code, so we need to provide for both
layers to exist.

> The tool would test to see if gcc existed still, but it would trust the user. This was to deal with the cases of:
>
> 1) I have a new test compiler in some .tar.gz/zip setup, it has no standard setup ( or Parts/Scons don't know about it yet as there is no tool) so we just set it up in the shell to get it to work quickly.
> 2) I want a quick hack to get something to work
> 3) I am setting up a new tool and I am trying to figure out what is missing in the env the tool setups from what is on the shell.
>
> I see 1) the most at work as we get these prototype setups that have something custom on it. One the testing is done on it they tend to disappear as whatever toolchain is on it becomes more "standard". Many of these cases have a custom gcc or intel compiler on it and the user just wants to have version of gcc to be used, not the "system" one. ( and for some reason it was not installed in /opt and or some other custom thing was done to it that make it difficult to use the standard tool without custom modification of tool code that the developer does not want to do)
>
> 2) is the next most common and seems to happen the most with people on a first pass make -> scons/parts pass or they are building on a cluster which has it own set of issues. Mostly it is nice to have an easy way to leak in the shell in controlled way as certain build cases are being corrected to be more repeatable. I view this as "hot wiring" the build, vs starting a build...

Yes, I agree this is a really interesting use case.

-- 
Gary