On Tue, Sep 30, 2014 at 10:39 AM, Kenny, Jason L <jason.l.ke...@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 _______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
