[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: disabling the built-in rules

From: Paul Smith
Subject: Re: disabling the built-in rules
Date: Mon, 17 Jul 2023 15:34:05 -0400
User-agent: Evolution 3.48.3 (by Flathub.org)

On Mon, 2023-07-17 at 20:41 +0200, Alejandro Colomar wrote:
> BTW, could you point out the problems with the following?
> MAKEFLAGS += --no-builtin-rules
> MAKEFLAGS += --no-builtin-variables
> MAKEFLAGS += --warn-undefined-variables
> This is what I currently use, and never had a big issue with it.  I
> don't care too much about old versions of GNU Make (although it might
> be a good idea to document in this thread what can go wrong with them
> too).  Is there any issue remaining with 4.4.1?

Well, automake DOES care about older versions of GNU Make, as well as
non-GNU versions of make.  So in the context of this thread, the above
is problematic.

I know of no problems with the above, if you are using the current most
recent version of GNU Make and don't need to be portable.

Something to be aware of is that this changes the behavior of both the
current makefile AND and sub-makes that you invoke.  If that's fine
with you, then no problem.  But many makefiles want to use recipes to
invoke builds of other packages using recursive make and those other
packages might not be so happy about this.

If you want to ensure that the builtin rule disable is limited to just
the current makefile and doesn't leak out to other invocations of make
then you need to use other methods, than setting MAKEFLAGS.

In general according to POSIX the MAKEFLAGS variable is reserved for
the implementation, other than being read from the environment at the
start of make's invocation.  GNU Make has made an effort to allow users
to effect the runtime behavior of make by setting this variable in the
makefile but if you check the NEWS and bug reports you'll see there
have been lots of problems over the years: it was maybe not the best
idea to try to have a "mixed use" variable that both users can set, and
that make itself uses to communicate runtime details to sub-makes.  The
big advantage to it is that it's intuitive for users... when it works
intuitively :p :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]