So I am not going to disagree. I believe we are both looking at a way to allow a tool to use random code to define itself. This should always exists as a fallback, In certain cases this may be the best options. I don't believe however that this should be the primary way we should advise people to write there tools.
I do believe that a SCons should have a system like what Parts suggests to help setup the a tool, however I think the setup should be not be strong coupled within SCons, this will allow different solution to be defined and allow SCons as a whole to improve. I should clarify the design tweak for use env was to allow a --use-env (with clear warning that this not what you want to do in a common case, and use at your own risk as you probably have bad build bits) and a common per tool defined variable to allow this to be control at a fine grain level. In the cases shown with gcc, Parts would currently looks at a GCC_VERSION, GCC_SCRIPT, GCC_INSTALLROOT variable define how it should setup the environment. I would add a GCC_USE_ENV to set to control what should be used. Given the tweaks Parts has with the "variables" objects in scons, this mean that these value could be defined on the command line as well as in the Sconstruct. ( I should point out that I think I have some bugs still in the GCC_SCRIPT logic as this was meant to be the way to avoid the use of "use env" logic as a whole, but I later learned that in certain cases even "script" would not work and "use env" was the best way) The current approach used in Parts also was based on my talks with Steve Knight originally at google. I know then and know that Gary ( and I at the time BTW,) wanted to make a more complex "generate()" call that had information about stuff in it. I think you see this same view in the current tool improvement proposal. Steve at that time was against it as we thought it was not needed, and added inconsistent way to set up stuff, and pushed me at that time to do more of a set of common "input" variable to control how a tools was setup. That is what I did. He has some other points of view as well why the other way was not as good, but I don't recall what it was. Still... I am not against the other direction either, just like to have a standard base set. For me the main thought is that we have the core Tool() and we would also have maybe a VersionTool() ( which is what I tend to deal more with in Parts) that subclasses from Tool(). For me it is about giving user structure to help then do it the best way ( while having freedom), vs saying you can do whatever you want, good luck! The latter way just make the system hard and confusing and scaring for ew people as there lacks any common way to do common things like select this "version"/(or versionless tools in this path, vs that path) of the tool. Jason -----Original Message----- From: Scons-dev [mailto:[email protected]] On Behalf Of Gary Oberbrunner Sent: Tuesday, September 30, 2014 9:49 AM To: SCons developer list Subject: Re: [Scons-dev] First Pillar of Future SCons Tools On Tue, Sep 30, 2014 at 10:39 AM, Kenny, Jason L <[email protected]> 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 [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev _______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
