Re: Per-source CFLAGS

• Previous message: Bruce Evans: "Re: Per-source CFLAGS"
• In reply to: Bruce Evans: "Re: Per-source CFLAGS"
• Next in thread: Bruce Evans: "Re: Per-source CFLAGS"
• Reply: Bruce Evans: "Re: Per-source CFLAGS"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sat, 21 Jun 2003 20:52:58 -0700
To: Bruce Evans <bde@zeta.org.au>

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.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

• Previous message: Bruce Evans: "Re: Per-source CFLAGS"
• In reply to: Bruce Evans: "Re: Per-source CFLAGS"
• Next in thread: Bruce Evans: "Re: Per-source CFLAGS"
• Reply: Bruce Evans: "Re: Per-source CFLAGS"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]