Re: [lmi] MAKEFLAGS

[Vadim Zeitlin]

On Tue, 9 Mar 2021 01:54:14 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 3/9/21 12:18 AM, Vadim Zeitlin wrote:
GC> > On Mon, 8 Mar 2021 22:57:11 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
GC> > 
GC> > GC> On 3/8/21 6:39 PM, Vadim Zeitlin wrote:
GC> [...]
GC> > GC> > [*] I wonder if there is some way to avoid lmi makefiles overriding 
my make
GC> > GC> >     options by explicitly setting MAKEFLAGS. I have to remember to 
do
GC> > GC> >     things like "make 
local_options==--what-if=/full/path/skeleton.cpp" to
GC> > GC> >     force recompiling the file instead of just using --what-if 
normally
GC> > GC> >     because of it and this is just annoying.
GC> > GC> 
GC> > GC> Relevant excerpts from 'GNUmakefile':
GC> > [...snipped...]
GC> > GC> I don't quite understand the problem. The only 'make' option I
GC> > GC> occasionally use is '-d', and 'make -d some_target' seems to work.
GC> > 
GC> >  I also regularly use --dry-run and --stop (because when I introduce some
GC> > bug into a wx header of the wx version I'm testing lmi with, I really
GC> > don't want to keep getting the same error several dozen times in a row).
GC> > I very rarely use -d however.
GC> 
GC> https://www.gnu.org/software/make/manual/make.html
GC> | The options ‘-C’, ‘-f’, ‘-o’, and ‘-W’ are not put into MAKEFLAGS;
GC> | these options are not passed down [to sub-makefiles].
GC> 
GC> -C <-> --directory=
GC> -f <-> --makefile=
GC> -o <-> --assume-old=
GC> -W <-> --what-if=

 Thanks, I've completely missed this.

GC> I don't know the rationale for not passing '-o' and '-W' down.

 The only hypothesis I have is that they might be used with relative paths
whose meaning would change in another makefile. But this doesn't seem
really convincing even to me.

GC> > I have to admit that I've never understood why do we bother with
GC> > MAKEFLAGS here rather than just passing these options directly to
GC> > submake.
GC> 
GC> I think that was addressed in the
GC> |  > GC> Relevant excerpts from 'GNUmakefile':
GC> |  > [...snipped...]
GC> above.

 My statement above was indeed a bit too sweeping. I do understand what it
does, I am just not sure whether it's a good idea to change the behaviour
of make like this rather than simply specifying the flags we want directly
when invoking submake. Doing this subverts a lot of the usual and, IMO,
very reasonable, expectations, such as that running "make" by default, or
at least when using "--stop", stops at first error. I can work around this
(but it took me time to find it the first time, and every subsequent time
when I forgot how to do it, which, unfortunately, happens more frequently
than I'd like), but it's just a source of unnecessary friction.

 If we really want to discuss the makefiles (but I'm not sure if we do), a
more interesting question might be whether we really need a separate
workhorse.make at all. I did read the paper[1] which inspired this approach
but I happen to completely disagree with it: the simple and obvious
"Explicit Path Method" mentioned there works perfectly well, I used it in
more projects than I can remember without ever having any problems with it
and there is no, or very little, duplication involved if you just define
the variable(s) for the object files. And, ironically, the only advantage
of the proposed method over it mentioned in the paper is the possibility to
do "make foo.o" which (very annoyingly!) doesn't work in lmi makefiles
anyhow.

[1]: https://make.mad-scientist.net/papers/multi-architecture-builds/

 Sorry for all this ranting, but lmi makefiles contain just too many
surprises which is the last thing I want from the build system. All I want
is for it to not get in my way of doing things, but with lmi makefiles I
always have the impression that they want _me_ to get out of their way and
let them do everything the way they want...

VZ

pgps1hW_nSsL7.pgp
Description: PGP signature