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
Description: PGP signature
