[Scons-users] Is there a way to turn this warning message off?

[William Blevins]

As Mark has already stated, this is a consistency problem.  Why do the
C/C++ tools complain by default when none of the other tools do?  It would
be reasonable to give a warning if the build called the C/C++ scanner for
example, but in the case above, it sounds like the tool is never used.  It
is not reasonable for the warning just because SCons in running on Windows
and SCons happens to support C/C++.

I have a usage question. Does the warning still appear in you set the
DefaultEnvironment( tools = [] )?

V/R,
William


On Sat, Jul 26, 2014 at 4:37 PM, Dirk Bächle <tshortik at gmx.de> wrote:

> On 26.07.2014 21:16, Mark A. Flacy wrote:
>
>> On Saturday, July 26, 2014 01:20:42 PM William Blevins wrote:
>>
>>> My opinion is that none should express warnings.
>>>
>>>  Well...
>>
>> Dirk brings up a good point and it all revolves around "What do you mean
>> when
>> you create an Environment()?" as well as "How *should* you create an
>> Environment()?"
>>
>> If the scons designers want to say "When you create an Environment, you
>> are
>> stating that you *need* all of the tools specified when the Environment is
>> constructed!", then it makes absolutely perfect sense that any tool the
>> environment is attempting to initialize should complain if it cannot.
>> IMO, if that's what you mean then if you don't specify a tool list when
>> you
>> create an Environment, then you shouldn't get _any_ tools.
>>
> Other users may have a different opinion about this. Here is how I see
> things:
>
> The "scons" script is a wrapper, trying to offer the underlying framework
> to users. It does this in a "convenient" way, by trying to find sensible
> defaults (see UserGuide, preface, sect. 1 "SCons Principles"). This is a
> problem, because there are several user groups, with different
> expectations...but we can set only *one* default.
> My guess is, that the msvs.py Tool (as part of the "default" list) assumes
> that a Windows user who tries to compile something, has a VisualStudio
> compiler installed. And I think this makes sense.
> Now, if some project offers an SConstruct to their users, which "just
> works and compiles all the stuff" on as many systems as possible...isn't it
> "convenient" to warn someone who doesn't even have a compiler installed?
> I'm not trying to win you over here, just describing a different
> perspective on things. ;)
>
>
>     Any warnings
>> should be optional and displayed via a debug command.  After all, you may
>> be
>> using the built-in actions to run your build or you are creating your own
>> builders and don't care what's in the tool set so the warning would be
>> annoying.
>>
> For the design of the framework, we want to be flexible and offer a great
> deal of extensibility (for tools and extensions like Parts, for example).
> Any kind of restriction we add, like "Tools have to do this/can't do that",
> undermines this goal in a way.
>
> We're currently working on a new design for how SCons handles Tools and
> their initialization. This will include the introduction of "ToolChains" as
> a set of single Tools, and make it much easier to select which Builders get
> added (for a specific version, if required).
>
> But the "default" setting of the tool list when constructing an
> Environment will probably stay, and with it the decision problem described
> above. We can change SCons to do it one way, or the other...people will
> complain about the standard settings anyway.
>
> Just my 2 cents,
>
> Dirk
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> http://four.pairlist.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20140726/47701564/attachment.html>