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