From owner-freebsd-arch@FreeBSD.ORG Sat Jun 21 20:53:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDDFA37B401 for ; Sat, 21 Jun 2003 20:53:09 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48BEC43F93 for ; Sat, 21 Jun 2003 20:53:08 -0700 (PDT) (envelope-from dschultz@OCF.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5M3r1Ja060590; Sat, 21 Jun 2003 20:53:03 -0700 (PDT) (envelope-from dschultz@OCF.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5M3qwQg060589; Sat, 21 Jun 2003 20:52:58 -0700 (PDT) (envelope-from dschultz@OCF.Berkeley.EDU) Date: Sat, 21 Jun 2003 20:52:58 -0700 From: David Schultz To: Bruce Evans Message-ID: <20030622035258.GB60460@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , arch@freebsd.org References: <20030622005124.GA59673@HAL9000.homeunix.com> <20030622114150.L54976@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030622114150.L54976@gamplex.bde.org> cc: arch@freebsd.org Subject: Re: Per-source CFLAGS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2003 03:53:10 -0000 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.