Date: Sat, 21 Jun 2003 20:52:58 -0700 From: David Schultz <dschultz@OCF.Berkeley.EDU> To: Bruce Evans <bde@zeta.org.au> Cc: arch@freebsd.org Subject: Re: Per-source CFLAGS Message-ID: <20030622035258.GB60460@HAL9000.homeunix.com> In-Reply-To: <20030622114150.L54976@gamplex.bde.org> References: <20030622005124.GA59673@HAL9000.homeunix.com> <20030622114150.L54976@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 22, 2003, Bruce Evans wrote:
> On Sat, 21 Jun 2003, David Schultz wrote:
>
> > The following patch adds support for per-file CFLAGS, which gets
> > appended to the command line after the global CFLAGS. I would
> > ...
> > I intend to use this feature for gdtoa, which is technically part
> > of libc, but also on a vendor branch and intended to stay that
> > way. The problem being addressed is that gcc at higher warning
> > levels has some inane warnings that the vendor and I consider
> > wrong, and yet people want to be able to compile libc cleanly at
> > these warning levels. As an example, gcc complains that the
> > expression 'a << b - c' must have parentheses because obviously
> > nobody remembers C's precedence rules. So here's just one
> > potential use of the new feature:
>
> For this, you really want per-file WARNS, since among other reasons
> compiler-dependent flags shouldn't be put in individual Makefiles.
>
> > Index: lib/libc/gdtoa/Makefile.inc
> > ===================================================================
> > RCS file: /cvs/src/lib/libc/gdtoa/Makefile.inc,v
> > retrieving revision 1.3
> > diff -u -r1.3 Makefile.inc
> > --- lib/libc/gdtoa/Makefile.inc 5 Apr 2003 22:10:13 -0000 1.3
> > +++ lib/libc/gdtoa/Makefile.inc 2 May 2003 09:31:15 -0000
> > @@ -16,6 +16,7 @@
> > .for src in ${GDTOASRCS}
> > MISRCS+=gdtoa_${src}
> > CLEANFILES+=gdtoa_${src}
> > +CFLAGS_gdtoa_${src}+=-w
>
> Do you need to turn off all warnings or just ones for non-broken
> precedence and a few other non-broken things? gcc doesn't give
> enough control over individual warnings, but it has -Wno-parentheses
> for turning off not much more than bogus warnings about natural
> precedence.
In this case, we really do want to ignore all the warnings. This
is vendor code, written in a style that makes it easiest for the
author to maintain. It so happens that -w is a de facto (if not
de jura) standard; it is supported by the GNU, Intel, and Sun C
compilers at least.
Per-file CFLAGS can't be used to disable warnings both selectively
and portably, but I believe that this mechanism is more
generically useful than are per-file WARNS. The latter would be
useful, too, but notice that it is a natural extension of per-file
CFLAGS. ;-)
> > # SINGLE SUFFIX RULES
> > .c:
> > - ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.IMPSRC}
> > + ${CC} ${CFLAGS} ${CFLAGS_${.IMPSRC}} ${LDFLAGS} \
> > + -o ${.TARGET} ${.IMPSRC}
> > ...
>
> Some rules are specified by POSIX, so they can't be changed. I don't
> see how ${CFLAGS} can be per-file directly, so the POSIX spec seems to
> be actively opposed to per-file CFLAGS.
??? You mean we can't add a variable that will normally expand to
nil? This seems like a compatible change, unless you're worried
about someone's makefile breaking because they defined
CFLAGS_foo.c to mean something else.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030622035258.GB60460>