[Scons-dev] Toolchain requirements

[anatoly techtonik]

I'd say, that to finally push this, somebody needs to start drawing
pictures. )

On Sun, May 25, 2014 at 8:14 PM, Gary Oberbrunner <garyo at oberbrunner.com>wrote:
>
>
>    - Allow installing external tools (pip install or ...)
>    -
>       - scons --version (or similar) should list installed tools and
>       toolchains
>
> Command line tool discovery checks is good.

1. What about "supported, but not installed" tools?
2. Should a tool versions be listed too (requires executing tool in most
cases)?

The current way to see what tools are available is:

    env = Environment()
    print(env['TOOLS'])

It doesn't seem possible with default environment or from interactive
session.

>
>    -
>       - missing external tools should give sensible errors
>
> Unclear. What is the current behavior?

>
>    - Tool setup must happen before reading SConstruct somehow
>    -
>       - DefaultEnvironment and all new Environments should know about all
>       tools
>
> Available or supported?

>
>    -
>       - alternative: lazy-construct DefaultEnvironment
>
> It is already lazy, no? What can be done is that tools in
DefaultEnvironment are
not always default. If DE is initialized as a result of Environment call,
and E has
limited subset of tools, DE should be initialized with limited subset for
this E.

>
>    -
>       - user-specified tools and toolchains need to be specifiable at
>       beginning of build
>
> Not sure. Why?

>
>    - User should be able to set default tools and toolchains
>    -
>       - unused tools shouldn't take any startup time
>
> This can be implemented already as mentioned above with DefaultEnvironment
memoization.

>
>    - Lazy init of tools and chains
>    -
>       - This is faster because unused tools don't matter
>       - It allows missing unused tools to not give errors, but missing
>       used tools can (and should)
>       - But it makes configuring environments much harder for users,
>       because they can't override or append to tool-provided variables until
>       those exist.  This would break a lot of existing SConstructs.
>       - We need to find some kind of compromise here:
>       -
>          - Explicitly list tools required by build (where?): this should
>          work well because only the needed tools will be initialized
>          - if nothing explicitly specified, fall back to current method
>
> Explicitly list all tools that are not default. Initialize them ASAP.
Initialize default tools after
dependency graph is constructed (unless tools are participating in graph
construction).

Would be nice to detect if a tool is participating in construction of
dependency graph, or
only in build phase.

>
>    - Within a tool:
>    -
>       - specify dependencies on other tools
>
> Can of worms. It is better to specify compatible toolsets externally.

>
>    -
>       - detect existence on system reliably, and without modifying env
>       -
>          - need better error messaging: ability to probe silently, but
>          also give sensible errors when needed
>
> Is it what SConf is for? I'd propose to replace it with more generic Check
framework,
which can probe tools, libs, includes etc. with caching and later usage in
statements.

>
>    -
>       - constructor needs to allow args: version, path, ABI, etc. (this
>       is important)
>
> As far as I know, SCons tools API don't have any constructors (which is
good), but
two functions - generate(env) and exists(env).

>
>    -
>       - allow for common setup (all C compilers, etc.) as now
>
> Can you rephrase? I don't get it.

>
>    -
>       - tools should be versioned so user can check if up to date, etc.
>    - Tool chains:
>    -
>       - either-or
>       - and
>       - collections
>
> IMHO toolchains should be visible, accessible and intuitive. Then they
will get ideal form themselves.

>
>    - Platform
>    -
>       - How much do we need to know about the platform, for tools to
>       initialize themselves?
>
> Build an explicit list "tool - info"?

>
>    -
>       - Cross-compilation comes into this, but may be too much to include
>       as a general part of this project.
>       - It may be useful to define toolchains and enable/disable them by
>       platform
>       - Of course the default toolchains need to be different by platform
>       - It may be possible for a default toolchain to just search for all
>       tools in a particular order and pick the first, as long as the
>       tool-dependency system is robust enough.
>
> 1. Detect what should be built
2. Detect what type of toolchain is needed
3. Detect what toolchains are available
4. Choose by priority (or by hint)

>
>    -
>       - Usability
>    -
>       - $CC etc. must never be left blank (without a prior tool-missing
>       error message at least) - this is a common problem
>
> Why it can not be left blank?

I propose a different mechanism. If there is an access to env[CC] - only
then do checks if it is blank,
so we need a mapping of env variables to toolchains.

>
>    -
>       - Must be backward compatible, at least for all common cases.
>
> Where are all common cases?

>
>    -
>       - Must not require any new user files (e.g. something in
>       site_scons) for normal operation
>       - Need a clear guide on requirements for new tools
>       -
>          - how to make a a tool
>
> I started, and I don't mind if anybody will continue.
http://techtonik.rainforce.org/2014/04/writing-scons-plugin-discovery.html

>
>    -
>       -
>          - how to include tests
>
> Hmm..

>
>    - Considerations
>    -
>       - "batteries included?"
>       -
>          - Each tool should do its best to set itself up, find
>          executables, etc.
>
> SCons should provide API for doing this and troubleshooting in the most
useful manner.
Therefore it will be good to have a few bad cases in mind.

>
>    -
>       -
>          - What about SCons policy of not relying on $PATH?  Maybe we
>          should relax that or have an option?
>
> Should not be relaxed. SCons was made to clear up the mess, not to add it
up. If you meant autodetection - it should
be explicit.

>
>    -
>       - minimum magic, maximum flexibility
>       - what about single tools?  Should every tool be required to be
>       part of a toolchain (even if it's just one tool)?  Maybe this doesn't
>       matter much.
>
> Single tools is a good entrypoint, so they should exist.

>
>    -
>       - Non-goals:
>    -
>       - New command-line args like autotools (platform, install paths,
>       etc.).  We should build something that would enable that, but it's too much
>       to bite off now.
>       - Persistence -- remember configuration on disk between runs.  This
>       is a performance enhancement which we should address only once we know it's
>       needed.  Better if we can design a system that's fast without needing this.
>    - References:
>    -
>       - http://www.scons.org/wiki/PlatformToolConfig (Greg's original
>       proposal)
>       - http://www.scons.org/wiki/RevampToolsSubsystem
>       - http://www.scons.org/wiki/PlatformToolConfigAlt (my proposal from
>       2008)
>       - http://www.scons.org/wiki/EvanEnhancedConfigurationPackageProposal
>
> --
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140527/9d0e1e3c/attachment-0001.html>