This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH to keep Jason from pointing out what a fool I am
- To: law at cygnus dot com
- Subject: Re: PATCH to keep Jason from pointing out what a fool I am
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Sun, 30 Aug 1998 16:27:12 -0700
- CC: egcs-patches at cygnus dot com
- References: <19765.904518304@hurl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
Jeffrey> In message
Jeffrey> <199808252036.NAA26392@smtp.earthlink.net>you write:
>> This patch enables "-W -Wall" even for stage1 builds, if the
>> native compiler is GCC. It's handy if you're building a
>> cross-compiler, or, if like me, you tend to just type `make'
>> when making a small change to the C++ front-end. Jeff?
Jeffrey> It would be better if we only had the warning flags set
Jeffrey> in one place in the Makefile.in or configure.in. Having
Jeffrey> them appear in multiple places in different files via
Jeffrey> different mechanisms is a pain.
I don't quite understand this criticism. I think that what you're
saying is:
For stage 2/3 builds we enable warnings by setting WARN_CFLAGS in
Makefile.in. For stage 1 builds, you (Mark) are proposing enabling
warnings in configure.in. That seems inconsistent.
Assuming I've paraphrased correctly, I'll try to answer the
criticism. We *unconditionally* set warnings for stage2/3 builds
because we *know* the compiler used with be GCC, and so it will
understand -W -Wall. Thus, there's no reason to use a configure
mechanism; we just set WARN_CFLAGS unconditionally in the Makefile.
For stage1, though, the compiler might not understand -W -Wall, so
this has to be done via a configuration check, and can't be set
unconditionally in Makefile.in.
Jeffrey> jeff
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com