[Scons-dev] First Pillar of Future SCons Tools

[anatoly techtonik]

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 <jason.l.kenny at intel.com> 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:scons-dev-bounces at scons.org] 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 <jason.l.kenny at intel.com> 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:scons-dev-bounces at scons.org] 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
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev



-- 
anatoly t.