[Scons-dev] First Pillar of Future SCons Tools

[Kenny, Jason L]

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