This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]
- From: Devang Patel <dpatel at apple dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 Aug 2002 19:15:03 -0700
- Subject: Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]
On Monday, August 12, 2002, at 07:06 PM, Daniel Jacobowitz wrote:
On Mon, Aug 12, 2002 at 06:59:28PM -0700, Devang Patel wrote:
On Monday, August 12, 2002, at 06:25 PM, Richard Henderson wrote:
On Mon, Aug 12, 2002 at 05:00:05PM -0700, Devang Patel wrote:
If the argument is that this warning comes from third-party header
files, the counter-argument is that the third party probably put
it in there for a reason, and that if you ignore the warning you
may well not understand the input constraints of the package.
What if it is coming from system headers ?
That still fits the description of third party from my point
of view: not the compiler and not the programmer.
It is different from third-party header. You may have freedom to use
particular version of third-party component but not system headers.
In Software release cycle, there are times when you're not allowed to
touch your source for a given release. They are frozen at a time.
Now imagine Mr. X
- Mr X is a software developer and develops software Z.
- Z is part of one particular OS released
targeted for particular date.
- Z is frozen as of today for OS release and it uses math library.
- Some other component in OS needs higher precision math and it is an
important component so system gets new math library.
- Math library provider puts a #warning message about new functions.
- Z uses -Werror and now it does not build.
You may argue that X needs to fix Z to use new APIs, but in real
life
if there are 1000 such projects and fixing and testing each of them
may take couple of months to stabilize everything.
That's not a valid reason, in my opinion. The new math library should
have #warning only off on a dev branch somewhere if it's sneaking in at
a time when components can not be upgraded to match!
It is sneaking in at a time when some component can be upgraded but not
all. Think if, Mr. X is an external developer. At last
minute OS release management may not want to wait for another drop of Z
from external sources but still wants to upgrade math lib. for other
components. And release manager can't release OS without Z.
That's release
management; you don't deprecate interfaces at the last minute.
When different component work on different time line, it is not easy to
synchronize and decide what is the 'last minute' for all project.
-Devang