lmi
[Top][All Lists]
Advanced

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

[lmi] MAKEFLAGS [Was: PATCH: tests build fixes for clang]


From: Greg Chicares
Subject: [lmi] MAKEFLAGS [Was: PATCH: tests build fixes for clang]
Date: Tue, 9 Mar 2021 01:54:14 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

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

https://www.gnu.org/software/make/manual/make.html
| The options ‘-C’, ‘-f’, ‘-o’, and ‘-W’ are not put into MAKEFLAGS;
| these options are not passed down [to sub-makefiles].

-C <-> --directory=
-f <-> --makefile=
-o <-> --assume-old=
-W <-> --what-if=

I don't know the rationale for not passing '-o' and '-W' down.
But if '--dry-run' and '--stop' work for you where '--what-if'
doesn't, then perhaps it's because of this.

> GC> Is the solution to change 'GNUmakefile' like this?
> GC> 
> GC> +MAKEFLAGS += \
> GC> -MAKEFLAGS := \
[...]
>  I thought this would work, but it doesn't.

Okay, then maybe it's because of the "feature" above.

> I have to admit that I've never
> understood why do we bother with MAKEFLAGS here rather than just passing
> these options directly to submake.

I think that was addressed in the
|  > GC> Relevant excerpts from 'GNUmakefile':
|  > [...snipped...]
above.



reply via email to

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