This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: handling of warnings


On Thu, 2003-08-14 at 02:14, Gerald Pfeifer wrote:
> On Wed, 14 Aug 2003, skaller wrote:
> > I can't afford to query gcc to find out what options it has ..
> > because I can't be sure I'm even running gcc. I don't
> > even know what OS I'm on .. could even be Windows using
> > MS compiler (though that's harder to make transparent :-)
> >
> > So detecting things down to the level of gcc version
> > is plain absurd for this system.
> 
> In other words, you want to use a set of command-line options that are
> supported by (some versions of) some compiler and hope that other versions
> of said compiler and other compilers will simply ignore those that don't
> apply?  Hoping that no option has different and conflicting semantics?
> 
> If that's the case, your build process sounds quite broken.

Yes, but it isn't the case. i want to use a set of *warning
control options* that are supported by (some versions of) 
gcc and other versions of gcc will simply ignore them.

Is that finally clear? Sorry if I failed to communicate well.
My build needs to be easy to adapt to any C++ compiler.
So I have the typical:

CC = g++ -w -pendant -ansi 

kind of line in the script. I want to support g++ by default.
The client is responsible for changing that line if another
compiler is used. They can of course tailor it to the
version of g++ they have... but having to do that detracts
considerably from the ability of the package to run on
Linux systems 'out of the box'.

> Gerald
> 
> PS: Gaby, I'm afraid this is starting to look like a troll. Don't feed "it".

Thanks for your confidence. As it happens Gaby knows who I am,
since we're both members of the C++ Standardisation committee.
.
I had a problem with using g++ and reported it by private
email to Gaby but got no response. Then I browsed the archives
of this list and found a long discussion of the issue in which
Gaby partook.

So I asked what had been done if anything (thanks Fergus for the reply),
and suggested a method that might solve this class of problems in
the future. 

Gaby suggested dynamically querying gcc to find what options
it supports and I have tried to explain why I think that isn't
appropriate for my package -- in my opinion as the developer,
using -w is a better option. But its a bad option to take,
so I hoped perhaps someone might agree to investigate an
alternative solution.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]