Re: CFLAGS and other flag variables

[Paul Smith]

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).

> 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.

You can see the default recipes and all variables they use, and what
they're defined to be, by running:

    make -pf/dev/null

Now that I notice, one alternative to redefining the rule would be to
just redefine the COMPILE.c variable:

    COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(EXTRA_CFLAGS) $(TARGET_ARCH) -c

then leave the default rule definition alone, which is:

    %.o: %.c
            $(COMPILE.c) $(OUTPUT_OPTION) $<

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