Date: Sun, 22 Jun 2003 20:27:41 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Schultz <dschultz@OCF.Berkeley.EDU> Cc: arch@freebsd.org Subject: Re: Per-source CFLAGS Message-ID: <20030622200641.D56263@gamplex.bde.org> In-Reply-To: <20030622085020.GA61926@HAL9000.homeunix.com> References: <20030622005124.GA59673@HAL9000.homeunix.com> <20030622035258.GB60460@HAL9000.homeunix.com> <20030622085020.GA61926@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Jun 2003, David Schultz wrote:
> On Sun, Jun 22, 2003, Bruce Evans wrote:
> > On Sat, 21 Jun 2003, David Schultz wrote:
> > > ??? 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.
> >
> > >From POSIX.1-200x-draft7.txt:
> >
> > % 23836 Default Rules
> > % 23837 The default rules for make shall achieve results that are the same as if the following were used.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > % ...
> > % 23864 SINGLE SUFFIX RULES
> > % 23865 .c:
> > % 23866 $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<
> >
> > This leaves little scope for modifying the default rules.
>
> The results *are* the same with the added ${CFLAGS_$<}, with the
> exception of the extra space in the argument list, and I don't
> think that's what the POSIX people were thinking. Is there a
The space is not part of the results :-).
> specific problem that this patch would cause for people expecting
> standards-compliant make magic (other than a name conflict)?
The spec says that a macro named CFLAGS_foo.c cannot modify the rule
unless the application makefile adds it to CFLAGS itself, Adding
magic macros to CFLAGS breaks this. Anyway, it's bogus to change
the separate set of POSIX rules, since the whole point of having a
separate set is for the POSIX rules to not be affected by FreeBSDisms.
> By the way, is your only complaint that I should not be making
> this modification in sys.mk? I'd be perfectly happy to remove
> that part. I really only care about bsd.lib.mk at the moment, and
I only care about the POSIX part of sys.mk for now. I think the
change isn't too obtrusive to put in sys.mk provided there is a
way to avoid it, and the POSIX part gives such a way.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030622200641.D56263>