By this I meant to have a --use-env or something value that would set the Scons environment "ENV" to that of the shell. 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... -----Original Message----- From: Scons-dev [mailto:[email protected]] On Behalf Of anatoly techtonik Sent: Tuesday, September 30, 2014 9:04 AM To: SCons developer list Subject: Re: [Scons-dev] First Pillar of Future SCons Tools This use_env logic - do you mean that tools rely on system environment and need it to be passed through by SCons? Or they still need SConstruct environment to patch it? On Tue, Sep 30, 2014 at 4:32 PM, Kenny, Jason L <[email protected]> wrote: > Thanks > > Yes it could be made to read complexly from a data file. There could > be value to do that. At the moment I did not want to write a parser to > some formatted data when I could say it all in python. I am pretty > sure that there are some tweak that need to made. For example allow > for the addition of use_env like logic as this is a common case that > is needed when adding new toolchains ( tend to happen a lot at work as > we get a lot of prototype setup to build under) > > Jason > > -----Original Message----- > From: Scons-dev [mailto:[email protected]] On Behalf Of > anatoly techtonik > Sent: Tuesday, September 30, 2014 7:16 AM > To: SCons developer list > Subject: Re: [Scons-dev] First Pillar of Future SCons Tools > > That's a really good starting point. Parts is awesome. Need to merge that > part with backward compatibility. > > gxx.Register( > # we assume that the system has the correct libraies installed to do a > cross build > # or that the user add the extra check for the stuff the need > hosts=[SystemPlatform('posix','x86'),SystemPlatform('posix','x86_64')], > targets=[SystemPlatform('posix','x86'),SystemPlatform('posix','x86_64')], > info=[ > GnuInfo( > #standard location, however there might be > # some posix offshoot that might tweak this directory > # so we allow this to be set > install_scanner=[ > PathFinder(['/usr/bin']) > ], > opt_dirs=[ > '/opt/' > ], > script=None, > subst_vars={}, > shell_vars={'PATH':'${GXX.INSTALL_ROOT}'}, > test_file='g++', > opt_pattern='gcc\-?([0-9]+\.[0-9]+\.[0-9]*|[0-9]+\.[0-9]+|[0-9]+)' > ) > ] > ) > > Interesting if it is possible to make it completely data oriented, like: > > --- > - name: gxx > platform: > buildhost: posix 32, posix 64 > target: posix 32, posix 64 > info: > - type: GnuInfo > search_paths: > - /usr/bin > opt_dirs: > - /opt > test_file: g++ > shell_vars: > PATH: '${GXX.INSTALL_ROOT}' > opt_pattern: 'gcc\-?([0-9]+\.[0-9]+\.[0-9]*|[0-9]+\.[0-9]+|[0-9]+)' > > > > > On Fri, Sep 26, 2014 at 6:21 PM, Kenny, Jason L <[email protected]> > wrote: >> I believe this is what I tried to achieve in Parts. >> >> For example look at this file >> http://parts.tigris.org/source/browse/parts/trunk/parts/parts/tools/G >> n >> uCommon/gxx.py?view=markup >> >> You see the different version, platforms ( and cross platform support) for >> g++ on posix, windows, darwin ,solaris and android for x86, x86_64, ia64, >> phi cards, and some arm cases. >> >> The system decides based on the host and target we are building for in a >> given environment what set to use to find and configure the env with. >> >> I found this to be a great too way to support different tools as it "easy" >> for people to see what is going on, and easy to add support for a new >> version of some tool. >> >> Jason >> >> -----Original Message----- >> From: Scons-dev [mailto:[email protected]] On Behalf Of >> anatoly techtonik >> Sent: Friday, September 26, 2014 8:01 AM >> To: SCons Development >> Subject: [Scons-dev] First Pillar of Future SCons Tools >> >> Hi, >> >> While patching Ansible stat module, the idea stormed me. >> >> The information that SCons collects about Tool should be passed >> declarative and static. >> >> There are some more sparks that feature-creep over it. >> >> Tool info should be declarative for better user experience while >> debugging and writing. >> Tool info should be static data. >> SCons itself decides how to combine tools based on static data that tool >> provides. >> >> Right now Tools `monkeypatch` SCons Environment dynamically, that's why it >> is SO HARD to understand what tool really provides. This in turn makes it >> REALLY HARD to study all tools to see common patterns. >> This in turn makes it ALMOST IMPOSSIBLE to squeeze all tools into >> mind to derive common abstract model for them without loosing >> possible (and >> crucial) details. And without abstract model we can not effectively >> communicate practical models and exchange ideas. The basic model for a tool >> should be static - what tool provides, if it exists or not. >> >> If Tool needs to hack SCons deeper, it should be done in a separate >> method. >> Monkeypatching of anything in SCons should be totally visible and >> accessible if needed. >> SCons level of application objects should be separated on the next level >> over Python objects. >> >> Better stop now. Hopefully at least the first part is clear. In summary - >> tool info should be readable as YAML. >> -- >> anatoly t. >> _______________________________________________ >> 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 > > > > -- > anatoly t. > _______________________________________________ > 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 -- anatoly t. _______________________________________________ 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
