Re: [boost] Are warnings acceptable artifacts from builds?

Subject: Re: [boost] Are warnings acceptable artifacts from builds?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-09-12 16:16:43

On Sat, Sep 12, 2009 at 6:50 AM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>
>> On Fri, Sep 11, 2009 at 4:40 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>>> AMDG
>>>
>>> Emil Dotchevski wrote:
>>>>
>>>> Well umm I'm not sure it's helpful at all then. It would be nice to be
>>>> able to pass to the compiler a list of paths it should consider
>>>> "3rd-party" and not warn unless the warning depends on user
>>>> constructs, which I guess fits your statement that it handles
>>>> templates okay. But maybe that's problematic for the same reasons
>>>> pragma once is.
>>>>
>>>
>>> You can use -isystem instead of -I.
>>
>> Could someone test this with Boost, that is, could someone confirm
>> that using this approach gets rid of (only) the unwanted warnings?
>
> Using -isystem is fine if, and only if the application developer believe that
> the Boost libraries that he is using were tested on exactly the same compiler
> and operating system, and the version tested was exactly the same, and the
> warnings were examined by the library developer and were found to be bogus.

You're thinking of warnings too narrowly. It seems like in your mind a
warning indicates a possible problem, the developer examines the code,
and by "fixing" the warning confirms that it's all good. With this
mindset, you've already assumed that the warning in question could
possibly indicate a problem, which isn't true for all warnings.

I'm not saying that this approach doesn't apply most of the time. I'm
with Robert: I'll look at warnings generated by tests on various
platforms if the testing framework highlights them, and more often
than not I'll fix the warning with appreciation. But when warnings
attempt to enforce design or question design decisions, I think that
it is not unreasonable for a library developer to disagree.

All things considered, in my opinion, -isystem is a good idea.

> Now, if I'm a building Boost as part of build process for my project, and
> my version of gcc is not in the regular regression matrix, or I use trunk
> snapshot with local modifications, then -isystem becomes rather questionable.

Sure, but in this case you're taking a significant risk already. Ask
me how I know. :)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode