[bug #62514] Regression. make ignores cli flags.

[Dmitry Goncharov]

Additional Item Attachment, bug #62514 (project make):

File name: sv62514_fix.diff   Size:4 KB


File name: sv62514_test.diff  Size:3 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #62514] Regression. make ignores cli flags.

[Dmitry Goncharov]

URL:
  

 Summary: Regression. make ignores cli flags.
 Project: make
Submitted by: dgoncharov
Submitted on: Tue 24 May 2022 12:16:45 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Tue 24 May 2022 12:16:45 AM UTC By: Dmitry Goncharov 
Commit f2771aa614d3a826b70973217c33f605fb4cd0c2 introduced function
reset_switches.
reset_switches wipes out certain flags specified on the command line.

/usr/bin/make is make-4.3.
make is the latest make from git.


$ cat makefile
MAKEFLAGS=-B
all:; $(info MAKEFLAGS=$(MAKEFLAGS))
$ /usr/bin/make -s
MAKEFLAGS=Bs
$ make -s
MAKEFLAGS=B
make: 'all' is up to date.
$


Flag '-s' is missing from MAKEFLAGS.
Also, the last output from make is "make: 'all' is up to date.".
This tells that '-s' is not in effect.
Similarly, reset_switches wipes out certain other options, e.g. -k, -S,
-l, --debug=, etc.
This patch deletes reset_switches and replaces it with a piece of code in
detect_switches to filter out duplicates.







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #62469] Make honors MAKEFLAGS= definition on the command line.

[Paul D. Smith]

Follow-up Comment #1, bug #62469 (project make):

I do agree that the current behavior is not correct, but I'm not sure that
disallowing MAKEFLAGS to be set on the command line is the right answer.  I'm
confident a lot of makefiles do do this, and although it's not a good idea I
don't know that we want to break them.

Also, unfortunately the POSIX spec is not very clear on this point but as far
as I can tell it's not _disallowed_ there which means that it might be a
violation of POSIX.

I'll need to think about the best way forward.

It may be that we simply have to make the command line options idempotent and
be able throw away and re-parse them at any time.  I don't know how far away
from that we are today.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/