Re: CFLAGS and other flag variables

Alejandro Colomar <[email protected]> Tue, 16 Jul 2024 17:28:28 +0200

Newsgroups	gmane.comp.gnu.make.general
Message-ID	<w2xqoyr5q7hj4vkw4v4o53awpyzaamrtp3vt4eaxi7wvg2pwr6@icuu3reef2v2>

Hi Paul,

On Tue, Jul 16, 2024 at 10:37:59AM GMT, Paul Smith wrote:
> On Tue, 2024-07-16 at 16:27 +0200, Alejandro Colomar wrote:
> > > Instead these standards recommend creating your own pattern rules
> > > to
> > > avoid being limited to only the default settings; for example:
> > > 
> > >      EXTRA_CFLAGS := $(shell pkgconf --cflags somedep)
> > > 
> > >      %.o : %.c
> > >              $(CC) $(EXTRA_CFLAGS) $(CFLAGS) $(CPPFLAGS)
> > > $(TARGET_ARCH) -c $(OUTPUT_OPTION) $<
> > 
> > Now that I see this, I wonder:
> > Is there any order preference between CFLAGS and CPPFLAGS?  I tend to
> > have CPPFLAGS first.  Probably it doesn't matter, but I'll ask just
> > in case.
> 
> It shouldn't matter since these sets of options are typically totally
> disjoint (being for the compiler and preprocessor respectively).

Okay.  BTW, since I define

	CPP := $(CC) $(CFLAGS)

and then use

	$(CPP) $CPPFLAGS)

which ends up being

	$(CC) $(CFLAGS) $(CPPFLAGS)

I've put everywhere CFLAGS first for consistency.

> 
> > Also: I didn't know about TARGET_ARCH.  Is that documented anywhere?
> 
> It's a variable added to the built-in recipe rules but it has no value
> by default.  I suppose it was intended to be used for flags like -m32
> or whatever but you should ignore it if you don't need it.

Hmm, thanks.  I'll ignore it for now.  :)

[...]

> Of course I suppose this relies on these default rules not changing,
> but I see no reason they would do so.

I use

	GNUMAKEFLAGS += --no-builtin-rules
	GNUMAKEFLAGS += --no-builtin-variables
	GNUMAKEFLAGS += --warn-undefined-variables

so, I redefine everything from scratch.  :-)

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

signature.asc (application/pgp-signature, 833 B)