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/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
--
anatoly t.
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
