[bug #62706] Restrict second expansion to targets which are being built.

[Paul D. Smith]

Follow-up Comment #4, bug #62706 (project make):

Since secondary expansion is not defined in POSIX it doesn't really matter
what POSIX says about this, IMO: we could easily define it either way.

However, I think this change is correct and the way I would expect things to
work, so it's a good one.


___

Reply to this item at:

  

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

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

Follow-up Comment #3, bug #62706 (project make):

Another thought on point 2 above.
Posix contains the following requirement.

"The make utility shall treat all prerequisites as targets themselves and
recursively ensure that they are up-to-date, processing them in the order in
which they appear in the rule."

Should word "processing" here be interpreted as any activity, including
secondary expansion (which posix does not define), needed to bring a
prerequisite up to date?

Secondary expansion of implicit rules in gnu make already satisfied these
requirements. This patch makes explicit and static pattern rules to satisfy as
well.



___

Reply to this item at:

  

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

[bug #62734] Have the test suite set ASAN env to ignore leaks.

[Dmitry Goncharov]

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

File name: sv62734.diff   Size:0 KB




___

Reply to this item at:

  

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

[bug #62734] Have the test suite set ASAN env to ignore leaks.

[Dmitry Goncharov]

URL:
  

 Summary: Have the test suite set ASAN env to ignore leaks.
 Project: make
   Submitter: dgoncharov
   Submitted: Sat 09 Jul 2022 06:57:40 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  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


___

Follow-up Comments:


---
Date: Sat 09 Jul 2022 06:57:40 PM UTC By: Dmitry Goncharov 
There are known memory leaks in make.
When make is build with ASAN checks enabled, those leaks fail the tests.
This patch sets ASAN env to ignore leaks. This simply makes it easier to run
the test suite with ASAN enabled builds of make.
Once (if ever) those known leaks are removed this commit can be reverted.







___

Reply to this item at:

  

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

Re: Goodbye to GNU make's "build.sh" ... ?

[Paul Smith]

On Sat, 2022-06-25 at 17:47 -0400, Paul Smith wrote:
> This leaves me with two options:
> 
>    1. Stop using gnulib, or at least sharply limit the modules we
> will include to those with trivial-enough configurations.
>    2. Abandon the build.sh script and require an existing make
> program in order to build a new version of GNU make.

What I ended up doing is importing parts of gnulib, but customizing the
imports to avoid explosions of secondary-effect modules being pulled in
and not needing a lot of extra machinery in the Makefiles.

I created a separate branch gnulib-port which contains unmodified
versions of gnulib modules, then merged them in and modified them. 
This should allow us to make use of git's merge facilities to import
newer gnulib versions more easily.

So far so good.

[bug #10593] $(shell) doesn't honor export but this is undocumented?

[Kaz Kylheku]

Follow-up Comment #8, bug #10593 (project make):

This solution works for me, thanks to $(shell var=val  command arg ...)
working fine:

  # put desired env vars into "shell_env" variable
  shell_exports := foo000=bar000 foo001=bar001
  
  # interpolate variable as a prefix of shell command
  $(info $(shell $(shell_exports) env | grep bar))

The Makefile can maintain a shell_exports variable as it sees fit, adding to
it with +=, removing using filter/filter-out and whatnot.





___

Reply to this item at:

  

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

[bug #10593] $(shell) doesn't honor export but this is undocumented?

[Paul D. Smith]

Update of bug #10593 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #7:

I added support for exporting variables into $(shell ...) operations.  I
didn't try to make it backward-compatible.  We'll see if this causes a problem
but I doubt that it will, and trying to create multiple ways to do it seemed
too onerous.


___

Reply to this item at:

  

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

[bug #62650] Fix an incorrect user message.

[Paul D. Smith]

Update of bug #62650 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Applied.  Thanks!


___

Reply to this item at:

  

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

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

[Paul D. Smith]

Update of bug #62514 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

Applied this with a few tweaks to the tests.

Thanks!


___

Reply to this item at:

  

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