Re: [lmi] Any clean way to suppress --keep-going?

[Vadim Zeitlin]

On Tue, 29 Sep 2020 20:27:55 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> You must have a very different style of working, and I just don't
GC> understand it.

 It's not even so much about which style of working is better, but, first,
about the mismatch between what lmi makefile does and what literally every
other makefile in existence does. I just don't think it's expected to
override the default make behaviour like this. Especially when it's so
simple to just use "-k" on the command line if/when it's wanted.

 So even if my way is completely wrong, lmi makefile still unexpectedly
changes a rather fundamental property of make. Of course, if you think that
my way is not just wrong, but contrary to the natural order of things and
should be eradicated and burned at stake, then it would explain overriding
it forcefully. But while I could be wrong, I don't think I deserve the
eternal damnation and wouldn't expect Spanish inquisition (but then, of
course, nobody does).


GC> If I make one mistake, I probably make many,

 I often make one mistake which results in dozens of errors in all the
files being compiled. This quickly (but not very quickly, i.e. it still
takes some time to wait for make to end, so I have to interrupt it using
Ctrl-C and hope no temporary files are left over from it or anything like
this) results in hundreds, if not thousands lines of diagnostics. I just
don't understand why would it be useful to see them N times instead of just
once.

GC> In a project that uses 'make' more conventionally, isn't every
GC> command echoed by default, so that diagnostics fly off the screen
GC> faster than you can press Ctrl-S?

 Most modern make-based projects either use Automake, which supports
"silent rules" by default, or do something similar themselves (e.g. Git),
so their output is actually very nice: just a single compile line for each
source file and nothing else (in absence of warnings). I wish lmi could do
it too, but I don't think it would be fruitful to start discussing this
now.

GC> Are you talking about the makefiles that build lmi itself,

 Yes.

GC> or something like 'install_libxml2_libxslt.make', which we'd probably
GC> both agree should be rewritten as a script? But even in that case,
GC> where building libxslt failed, I was glad that 'install_msw.sh'
GC> didn't have "set -e", so I could see that libxslt was the only
GC> thing that broke the other day.

 I would have been very upset to waste a lot more time on building things
after the first failure, which was already fatal, but I don't use
install_msw.sh anyhow, so I won't discuss it neither.

GC> I'm so used to piping into 'less' that I just automatically search
GC> for '\*\*\*'.

 You're probably using make in a much more batch-like way. I'm too
impatient for this and want to get immediate mortification, so that I can
fix my errors as quickly as possible.

GC> Have you tried
GC>   https://www.gnu.org/software/make/manual/make.html#index-_002dS
GC> '-S' or its synonyms '--stop' and '--no-keep-going'?

 Yes, but MAKEFLAGS assignment overrides it. To override MAKEFLAGS in the
makefile, the only choice, AFAIK, is to set MAKEFLAGS explicitly on make
command line.

GC> Or have I imposed '--keep-going' so forcibly as to block '--stop'?

 Yes.

GC> Adding a target to test that, right below where MAKEFLAGS is set:
GC> 
GC>  MAKEFLAGS := \
GC>    --no-builtin-rules \
GC>    --no-builtin-variables \
GC>  
GC> +xyzzy:
GC> +       @echo "MAKEFLAGS is: '$(MAKEFLAGS)'"
GC> +
GC> 
GC> and then running a few tests suggests that I may have:
GC> 
GC> $ GNUMAKEFLAGS="--no-keep-going" MAKEFLAGS="--no-keep-going" make 
--no-keep-going xyzzy
GC> MAKEFLAGS is: 'krR'
GC> 
GC> No, wait, that test is wrong--instead, write "MAKEFLAGS" after "make":
GC> 
GC> $ make xyzzy                                                          
GC> MAKEFLAGS is: 'krR'
GC> 
GC> $ make MAKEFLAGS= xyzzy
GC> MAKEFLAGS is: ''
GC> 
GC> So that works, while this doesn't:
GC> 
GC> $ make --no-keep-going xyzzy
GC> MAKEFLAGS is: 'krR'
GC> 
GC> but the important thing is that one of them works.

 Sorry, I don't understand what works. AFAICS 'k' is still preset in
MAKEFLAGS even when --no-keep-going is specified on the command line which
is exactly the problem which I'm trying to solve.

GC> I was thinking of something like the following patch, but doesn't
GC>   make MAKEFLAGS= xyzzy
GC> above already do what you want, just as well?

 This removes --no-builtin-{rules,variables} too, which could change the
makefile behaviour. I am not sure if I can safely do this, which is why the
only workaround I know is to do "make MAKEFLAGS=-rR". Which does work
(until you add "override" to the makefile to really impose the One True
Way, anyhow), but is rather ugly. Worse, I keep forgetting about it all the
time. On the bright side, this discussion should allow me to quickly find
it in lmi archives the next time it happens...

GC> -MAKEFLAGS := \
GC> +# add a comment explaining this:
GC> +
GC> +LMIMAKEFLAGS := \
GC>    --keep-going \
GC>    --no-builtin-rules \
GC>    --no-builtin-variables \
GC>  
GC> +MAKEFLAGS := $(LMIMAKEFLAGS)

 This doesn't really change anything, does it?

GC> > Ideally, of course, I'd say that this option should be just
GC> > removed and then "make -k" be used when/if it's needed, but as I don't
GC> > think you'd agree to do this
GC> 
GC> Well, I can report how many times I made 'GNUmakefile' on any day.

 FWIW I have an alias ms for "make -s". If I were using "make -k" as often
as you do, I'd definitely make an alias ("mk"?) for it too. Huffman coding
is really helpful for the most often useful commands (FWIW mine are
"g"=git, "cd", "la"=ls-with-the-options-I-like, "ms", "pd"=pushd, "rg" and
"v"=less in alphabetical order).

GC> I'd make the "LMIMAKEFLAGS" change above (after careful testing)
GC> if there's a real advantage to it.

 No, I really don't think there is any.

 Sorry for the rant, but this is really annoying and just seems unnecessary
painful. I'll stick to "make MAKEFLAGS=-rR" (and alias it to mklmi or
something) for now.

 Regards,
VZ

pgpRlTABHCmdy.pgp
Description: PGP signature