[Scons-users] Retrieving variables

[Stefan Seefeld]

On 17.06.2016 10:56, Bill Deegan wrote:
> Stefan,
>
>
>
> On Fri, Jun 17, 2016 at 6:35 AM, Stefan Seefeld <stefan at seefeld.name
> <mailto:stefan at seefeld.name>> wrote:
>
>     Hi Bill,
>
>     sorry for a belated followup.
>
>     On 14.06.2016 15:47, Bill Deegan wrote:
>
>     >
>     >     While this may work, it really looks like a kludge.
>     >
>     >
>     > not sure what you are referring to here..
>
>     Explicitly instantiating a tool seems to imply that I want to override
>     the automatic choice, so the semantic is (at least slightly) changed. 
>
>
> Not exactly.  It means you want to be explicit about loading tools.
> You may not want to load all the available ones, it is also an
> optimization as loading all tools can slowsdown scons startup.
> So in the case where you only need tools x,y, and z, you can specify
> only those.
> In your case you want to defer loading msvc until you are able to set
> some variables to aid in its configuration.
> This is not an odd or unusual event to do any of the above.

I agree. But to be able to load that tool (msvc) explicitly, I need to
duplicate the SCons-internal logic to determine whether MSVC is
available at all on the given platform, and I have yet to figure out how
to do that.

>  
>
>
>     But experimenting with this, I ran into other issues, as well:
>
>     >
>     > env=Environment(tools=[], variables=vars)
>     >
>     > env['TARGET_ARCH'] = env['arch']
>     > env.Tool('msvc')
>     >
>     > Should more or less do what you want.
>
>     Here is my current logic:
>
>       env = Environment(toolpath=['config'],
>                         tools=['default', 'build_variants', 'boost_libs',
>     'boost_tests'],
>                         variables=vars)
>       env['TARGET_ARCH'] = env['arch']
>       env.Tool('msvc')
>
>     which yields:
>
>       EnvironmentError: No module named msvc:
>
>     Any idea why ? (Is SCons by any chance looking for tools *only* in
>     config/ ?) But it gets slightly worse: My `config/` directory actually
>     contains a 'msvc.py' module. And with that, I get a different error:
>
>
>       AttributeError: 'module' object has no attribute 'generate':
>
>     because that module isn't a 'tool' at all (and as it isn't listed
>     in the
>     'tools' constructor argument above, I had assumed it would not be
>     read).
>     So, I don't understand the precise semantics of the 'toolpath' and
>     'tools' constructor arguments. (I thought the 'default' value was
>     supposed to tell SCons to load all the built-in tools first, and only
>     add the other ones mentioned above from the provided toolpath.
>     Please clarify the documentation.
>
>
> The documentation is fairly clear on this (from manpage).  Sounds like
> you are telling SCons you have tools in config, then you have a file
> named msvc.py which scons trys to load as the msvc tool which doesn't
> specify the required methods and so scons fails loading the tool. This
> is pretty much what the doc snippet below says. See bit highlighed in red.
>
> Non-built-in tools may be specified using the toolpath argument:
>
> env = Environment(tools = ['default', 'foo'], toolpath = ['tools'])
>
> This looks for a tool specification in tools/foo.py (as well as using
> the ordinary default tools for the platform). foo.py should have two
> functions: generate(env, **kw) and exists(env).
> The|generate()| function modifies the passed-in environment to set up
> variables so that the tool can be executed; it may use any keyword
> arguments that the user supplies (see below) to vary its
> initialization. The |exists()| function should return a true value if
> the tool is available. Tools in the toolpath are used before any of
> the built-in ones. For example, adding gcc.py to the toolpath would
> override the built-in gcc tool. Also note that the toolpath is stored
> in the environment for use by later calls to *Clone*() and *Tool*()
> methods:
>
> If you specify a toolpath, then really no files which are not tools,
> especially if they are named the same as existing tools, should be in
> that directory.

OK, fair enough. But that only answers one of the two questions. If I
(re-)move the msvc.py module from config/, I get the error

  EnvironmentError: No module named msvc:

What do I need to do to tell SCons to *also* look in its default
location(s) ? Isn't this error in conflict with the documentation you
cite above, specifically "This looks for a tool specification in
tools/foo.py (as well as using the ordinary default tools for the
platform)." ?

Thanks,
        Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...