Per-source CFLAGS

[David Schultz]

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.