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/Gn > 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
