[Scons-users] Retrieving variables

[Bill Deegan]

Is there a msvc.pyc or .pyo still in your config dir?

-Bill

On Fri, Jun 17, 2016 at 8:06 AM, Stefan Seefeld <stefan at seefeld.name> wrote:

> 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...
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160617/fd23c456/attachment-0001.html>