[bug #60841] misleading statement in the manual

2021-06-27 Thread Dmitry Goncharov
Additional Item Attachment, bug #60841 (project make):

File name: sv_60841_doc_fix.diff  Size:1 KB




___

Reply to this item at:

  

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




[bug #60841] misleading statement in the manual

2021-06-27 Thread Dmitry Goncharov
URL:
  

 Summary: misleading statement in the manual
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 27 Jun 2021 09:57:28 PM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

The manual states in 6.10

"When make runs a recipe, variables defined in the makefile are placed into
the environment of each shell."

This statement gives impression that each make variable defined in the
makefile is placed to the env of each child, by default.




___

Reply to this item at:

  

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




[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

2021-06-27 Thread Robert Sachunsky
Follow-up Comment #9, bug #44853 (project make):

related/duplicate: #45763

I would like to add that (to my surprise) even the workaround offered by the
file function (and specifically documented for this purpose in section 8.6 of
the manual, with example recipes) _may not work_:


program: $(OBJECTS)
 $(file >$@.in,$^)
 $(CMD) $(CMDFLAGS) @$@.in
 @rm $@.in


It seems like the reason for me was that the makefile contained an *export*
directive (for all variables), which causes *OBJECTS* getting appended to the
envp of the execve call of the recipe. Since E2BIG is caused by _either_ the
argv _or_ the envp argument, the result is the same (just the error message is
confusing).

So as long as make has no general solution for E2BIG, I recommend at least
documenting that *.EXPORT_ALL_VARIABLES* or *export* will break the file
function workaround.

___

Reply to this item at:

  

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