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

[Dirk Bächle]

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