bug-make
[Top][All Lists]
Advanced

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

Re: Handling of MAKEFLAGS


From: Paul Smith
Subject: Re: Handling of MAKEFLAGS
Date: Sun, 28 Jan 2024 19:07:55 -0500
User-agent: Evolution 3.50.3 (by Flathub.org)

On Thu, 2024-01-11 at 00:37 -0500, Dmitry Goncharov wrote:
> You are designing a new feature, aren't you? Specifically, the
> ability to unset -e.  If really needed, a makefile can reset -e on
> the command line for submake and have submake do the work. 
> Alternatively, it is possible to introduce the opposite switch, just
> like -S and -k.

Thinking about it more I've decided I don't think this is needed.

Why would -e be used?  It means that the person invoking make decided
that they want their environment variables to take precedence over
variables in the makefile.  I think this is a bad idea, but I don't
think it's right for the _makefile_ to be able to override this
decision and _disable_ the -e option again.

Of course it's possible that the makefile added the -e option not the
user on the command line but, well... as you say they can use a sub-
make if they really want to override it.

I just think the -e option is a bad idea in all the ways so I don't
want to go to a lot of trouble to allow fancy behaviors.

> 
> i agree that the makeflags business is overly complex. i feel, the
> main issue is that makeflags serves two functions, it carries command
> line switches to submake and it allows a makefile to set switches.

Yes, that may be so.  As you say it's kind of moot now.  Plus, there's
some elegance to allowing it, from the user's perspective, since that's
how they set variables in their environment etc. as well.

But it definitely leads to a lot of effort in the implementation to try
to keep it all straight.

-- 
Paul D. Smith <psmith@gnu.org>            Find some GNU Make tips at:
https://www.gnu.org                       http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist






reply via email to

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