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