On 2024-07-17 02:11, Alejandro Colomar wrote:
> Hi Kaz,
>
> On Tue, Jul 16, 2024 at 05:10:00PM GMT, Kaz Kylheku wrote:
>> because there is a built-in recipe for making .o files
>
> Except that I do:
>
> MAKEFLAGS += --no-builtin-rules
> MAKEFLAGS += --no-builtin-variables
> MAKEFLAGS += --warn-undefined-variables
>
> Sorry for not mentioning that.
OK; by the way, --no-builtin-variables implies --no-builtin-rules.
Secondly, where are you doing this? It has no effect on the
currently executing make. If you have rules which call make
recursively, these flags will affect those invocations.
>> Programs should use CFLAGS, CPPFLAGS, LDFLAGS and LDLIBS if those
>> are set on the make command line or in the environment.
>
> Hmmmm, for the time being, I won't be able to use them from the
> environment, because that conflicts with
>
> MAKEFLAGS += --no-builtin-variables
This does not make external variables go away. If CFLAGS is
defined on the environment or passed on the command line,
it still appears inside make. Just make won't define it
if it doesn't exist.
> I'll need the next release of make(1) to be able to use an empty default
>
> CFLAGS ?=
What release is that?
In make 4.1 from 2014, the above CFLAGS ?= defines CFLAGS if CFLAGS doesn't
exist.
Given
# CFLAGS ?=
$(info $(CFLAGS))
if I run "make -R --warn-undefined-variables", I get a warning on $(CFLAGS).
If I uncomment the CFLAGS ?= line, it goes away.
>
>> If you want to use built-in recipes, and your code needs
>> certain cflags (like for instance C dialect selection), then
>> you can add that to CFLAGS:
>>
>> CFLAGS += -std=c17 -Wmy-favorite-warning-option
>
> There's a problem with that. My selection would have preference over
> the user, since it's specified later in the command line.
That's not the problem with that. The problem with that is that
if we have this in the Makefile:
CFLAGS += --our-important-flag
and the user adds CFLAGS += --extra-flag on the make command line,
that presence on the command line obliterates our append above;
our important flag is gone.
This is the reason why you really want your own private variables,
and have to define your own recipes which look like this:
$(CC) $(CFLAGS) $(MY_CFLAGS) ...
rather than trying to append to CFLAGS.
Because then the user can freely manipulate CFLAGS
without obliterating your important flags in
MY_FLAGS. (If they want to obliterate those, they have to
learn about MY_CFLAGS.)
It would be useful if Make itself defined this mechanism in more detail;
that is to say, if the built-in recipes contained more variables for
more parties, like
$(CC) $(CPPFLAGS) $(OWN_CPPFLAGS) $(EXTRA_CPPFLAGS) \
$(CFLAGS) $(OWN_CFLAGS) $(EXTRA_CFLAGS) ...
The names would be standard and everyone would understand that
distros typically control the plain variables like CFLAGS,
that their own Makefile can assert its essential flags in the
OWN_CFLAGS variable, and the user who is trying to build the
program through the distro build can use EXTRA_CFLAGS
to customize something (e.g. temporarily during debugging).
>> If CFLAGS exist,
>
> The bad part is that CFLAGS _always_ exists (unless you remove it on the
> command line with -R, which is kind of nonsensical, because whoever runs
> make(1) already can override it by specifying a different value
> explicitly).
Though it exists since it is one of the predefined variables, it
has a blank value. So for instance CFLAGS ?= -O2 kicks in, if there
is no CFLAGS on the command line or in the environment, even though
CFLAGS exists due to being defined by make.
It's almost as if CFLAGS is not really defined. (Except that if you're
using warning on undefined variables, CFLAGS doesn't trigger
anything unless you -R it out.)
> Thankfully, the next version of make(1) will fix that historical bug.
>
>> assume that the user/distro is using that to
>> control optimization and possibly other code generation options.
>> You can disable optimization by adding -O0 after $(CFLAGS).
>
> That would be overriding the user's choice, which I don't think is a
> good idea.
Right; I only mean temporarily for debugging. The user themselves
could be doing that. They have CFLAGS coming out of the distro build
they are using, and don't want to touch that. So using whatever means
is available in your Makefile, they may be able to add -O0 after
the CFLAGS. E.g. if your custom recipes have $(CFLAGS) followed
by $(EXTRA_CFLAGS), the user can learn about that and specify
EXTRA_CFLAGS=-O0.
(Incidentally, the author of the program should have a say in whether
optimization applies. If the program does things that break under
optimization, it would make sense to ship it such that it builds
-O0 even if a distro specifies -O2.
I have a program that can't work with link-time optimizations (LTO)
Some distros are starting to enable them, and so I have to counteract
that in the Makefile. I understand that the distro people like the
shiny new way to make things go faster, but we have to let it go
in that program.)
