Re: "make -jN" requires mechanical changes to a Makefile

[Henrik Carlqvist]

On Mon, 13 May 2019 00:05:59 +0200
Bruno Haible  wrote:

> Howard Chu wrote:
> > >> Example with one rule creating 4 files:
> > >>
> > >> all : copy1 
> > >>
> > >> copy1: Makefile
> > >> install -c -m 644 Makefile copy1
> > >> install -c -m 644 Makefile copy2
> > >> install -c -m 644 Makefile copy3
> > >> install -c -m 644 Makefile copy4
> > > 
> > > I think the "representative" file should be copy4 here, because it's
> > > the one that gets created last.
> > 
> > That sort of thing is only true in serial make, you can't rely on it
> > in parallel make.
> 
> The sequence of lines of the recipe of a rule gets executed in order,
> even in parallel make, no?

Yes, they will be run in sequence even with parallel make and copy4 might
be a better known target than copy1.

regards Henrik

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #55243] Request for a way to indicate that the same recipe execution produces several targets

[Paul D. Smith]

Update of bug #55243 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Duplicate of bug #8297

___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #56025] .RECIPEPREFIX doesn't parse line continuations inside function calls

[Paul D. Smith]

Follow-up Comment #2, bug #56025 (project make):

I agree that this is not right.  The handling of the prefix character needs a
bit of work.

However, I should say that I intended the prefix character to ONLY be used to
introduce the initial line of a recipe.  Maybe that intention needs some
rethought.

I'll leave this open to consider it.

___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #55944] make-4.2 arm64 w10 test

[Paul D. Smith]

Update of bug #55944 (project make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Sorry, but there's no chance I'll be able to do anything about this.  If
someone has access to this system and wants to work on figuring out why we're
getting this error from a header that's part of the compiler, not part of GNU
make:


c:\program files (x86)\windows kits\8.1\include\um\winnt.h(147): fatal error
C1189: #error:  "No Target Architecture"


and whatever other failures (don't worry about the warnings) then I'll be
happy to apply an appropriate patch.  I'm going to close this for now but if
someone provides a patch I can re-open it.

___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #56206] ifndef false positive for exported variable

[Paul D. Smith]

Follow-up Comment #2, bug #56206 (project make):

Somehow my previous comment was truncated (I do so HATE Savannah markup :( ):


There is another assignment operator for variables, ‘?=’. This is called a
conditional variable
assignment operator, because it only has an effect if the variable is not yet
defined.
This statement:

  FOO ?= bar

is exactly equivalent to this (see The origin Function):

  ifeq ($(origin FOO), undefined)
FOO = bar
  endif

Note that a variable set to an empty value is still defined, so ‘?=’ will
not set that variable. 


___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #56206] ifndef false positive for exported variable

[Paul D. Smith]

Update of bug #56206 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This behavior is correct.  The confusion is because the ?= operator and the
ifndef operator have different behaviors for variables which are defined to
have an empty value.

ifdef/ifndef test whether the expansion of the variable is the empty string or
not:


ifndef variable-name

If the variable variable-name has an empty value, the text-if-true is
effective;
otherwise, the text-if-false, if any, is effective.


However, the ?= operator tests whether the variable is actually defined or
not, not whether it has an empty value:


There is another assignment operator for variables, ‘?=’. This is called a
conditional
variable assignment operator, because it only has an effect if the variable is
not
yet defined. This statement:

  FOO ?= bar

is exactly equivalent to this (see The origin Function):

  ifeq ($(origin FOO), undefined)
FOO = bar
  endif

  Note that a variable set to an empty value is still defined, so ‘?=’
will not set that variable. 
-verbatim=

___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Howard Chu wrote:
> >> Example with one rule creating 4 files:
> >>
> >> all : copy1 
> >>
> >> copy1: Makefile
> >> install -c -m 644 Makefile copy1
> >> install -c -m 644 Makefile copy2
> >> install -c -m 644 Makefile copy3
> >> install -c -m 644 Makefile copy4
> > 
> > I think the "representative" file should be copy4 here, because it's the one
> > that gets created last.
> 
> That sort of thing is only true in serial make, you can't rely on it in 
> parallel make.

The sequence of lines of the recipe of a rule gets executed in order,
even in parallel make, no?

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Howard Chu]

Bruno Haible wrote:
> Henrik Carlqvist wrote:
>> Example with one rule creating 4 files:
>>
>> all : copy1 
>>
>> copy1: Makefile
>> install -c -m 644 Makefile copy1
>> install -c -m 644 Makefile copy2
>> install -c -m 644 Makefile copy3
>> install -c -m 644 Makefile copy4
> 
> I think the "representative" file should be copy4 here, because it's the one
> that gets created last.

That sort of thing is only true in serial make, you can't rely on it in 
parallel make.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Henrik Carlqvist wrote:
> Example with one rule creating 4 files:
> 
> all : copy1 
> 
> copy1: Makefile
> install -c -m 644 Makefile copy1
> install -c -m 644 Makefile copy2
> install -c -m 644 Makefile copy3
> install -c -m 644 Makefile copy4

I think the "representative" file should be copy4 here, because it's the one
that gets created last.

Otherwise, when the user interrupts "make" after copy1 was created but before
copy2, copy3, copy4 are created, and then retries "make" again, the second
'make' invocation will fail somewhere when it references copy2...copy4.

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Henrik Carlqvist]

On Sun, 12 May 2019 22:23:12 +0200
Bruno Haible  wrote:
> Now, when my use-case is:
>   - one rule that produces N files (N > 1),
>   - I want "make" to execute the rule only once, not N times,
> even with parallel make.
> What is the solution?

I think that the only good solution is to make sure than only 1 of the N
created files is a known target for the Makefile. If you write single
rules that on one call creates multiple targets your Makefile will not be
compatible with parallel make.

Example with one rule creating 4 files:

all : copy1 

copy1: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4

A better way would be to have one rule to create multiple targets, but
only on target for each call, example:

all: copy1 copy2 copy3 copy4

copy%: Makefile
install -c -m 644 Makefile $@

The above simple Makefile would be fully compatible with parallel make.

regards Henrik

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

[Paul D. Smith]

Update of bug #8297 (project make):

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

___

Follow-up Comment #10:

I made some changes to the patch and pushed it to Git master.

___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Hi Paul,

> > The real workaround goes like this:
> > 
> > ===
> > all : copy1 copy2 copy3 copy4
> > 
> > copy1: Makefile
> > install -c -m 644 Makefile copy1
> > install -c -m 644 Makefile copy2
> > install -c -m 644 Makefile copy3
> > install -c -m 644 Makefile copy4
> > copy2 copy3 copy4: copy1
> > ===
> 
> This is not fully-correct either:
> 
>   $ make
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> 
>   $ rm copy3
> 
>   $ make
>   make: Nothing to be done for 'all'.

Indeed. Thank you for having spotted this; otherwise I would have put a
broken rule into GNU gettext.

Now, when my use-case is:
  - one rule that produces N files (N > 1),
  - I want "make" to execute the rule only once, not N times,
even with parallel make.
What is the solution? The documentation page [1] explicitly does NOT mention
this use-case for multiple targets on the same rule.

You mentioned splitting the rule into one rule per file. But bison does not
work this way; it really produces two files at once. And for other rules
I mentioned Automake limitations.

Parallel make is of growing importance, because Debian now uses parallel builds
by default (quote: "debhelper >= 10 defaults to parallel build").

Bruno

[1] https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #42288] limit parallelism based on available memory

[Paul D. Smith]

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

Limiting jobs based on available memory, like -l but for memory, would be
significantly less complicated than the original request of expressing how
much memory a recipe might consume and having make defer running recipes that
are too large and instead choose recipes which fit.

However, even though a "memory limit" feature is more straightforward to
implement it still has many issues that need to be resolved before it can be
implemented: primarily, how do we measure memory used (or probably more
reasonably, memory still available)?  And how to do it portably?

___

Reply to this item at:

  

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


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Paul Smith]

On Sun, 2019-05-12 at 18:07 +0200, Bruno Haible wrote:
> This workaround doesn't actually work (in the actual case of GNU gettext):
> it fails the "make distcheck" verification.
> 
> The real workaround goes like this:
> 
> ===
> all : copy1 copy2 copy3 copy4
> 
> copy1: Makefile
> install -c -m 644 Makefile copy1
> install -c -m 644 Makefile copy2
> install -c -m 644 Makefile copy3
> install -c -m 644 Makefile copy4
> copy2 copy3 copy4: copy1
> ===

This is not fully-correct either:

  $ make
  install -c -m 644 Makefile copy1
  install -c -m 644 Makefile copy2
  install -c -m 644 Makefile copy3
  install -c -m 644 Makefile copy4

  $ rm copy3

  $ make
  make: Nothing to be done for 'all'.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Hi,

I wrote:
> The workaround is to introduce an intermediate target:
> 
> ===
> all : copy1 copy2 copy3 copy4
> 
> copy1 copy2 copy3 copy4: install-copies
> .PHONY: install-copies
> install-copies: Makefile
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> ===

This workaround doesn't actually work (in the actual case of GNU gettext):
it fails the "make distcheck" verification.

The real workaround goes like this:

===
all : copy1 copy2 copy3 copy4

copy1: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
copy2 copy3 copy4: copy1
===

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make