[bug #60435] Chained pattern rules with multiple targets not removing all intermediate files

[Paul D. Smith]

Update of bug #60435 (project make):

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

___

Follow-up Comment #2:

I applied these patches with some light tweaking.

Thanks for the report (and thanks Dmitry for the patch!)

___

Reply to this item at:

  

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

[bug #60399] Incorrect dependencies with grouped targets

[Dmitry Goncharov]

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

There is this difference in behavior between the 2 makefiles.
In the cause of

.PHONY: b
a b&:; touch a b

b is phony and a is not phony.

In the case of

.PHONY: force
b: force
a b&:; touch a b

Both a and b depend on force.

Do you think make should behave the same in both cases?

___

Reply to this item at:

  

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

[bug #60399] Incorrect dependencies with grouped targets

[Paul D. Smith]

Update of bug #60399 (project make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #2:

Re-reading this I think I want to retract my earlier comment that this does
not seem right.  I think that make's behavior here is correct.

But, I'm willing to be convinced otherwise if there are good arguments for
it.

The way a grouped target works is that a single invocation of the recipe
builds ALL targets.  This implies that if any single target in the set of
grouped targets is out of date, then all the targets will be built.  In this
example b is always out of date, and so the targets will always be built.

Just to check I tried using a pattern rule with multiple targets in this same
way (forcing only one of the targets to be out of date then explicitly
building the other one) and it worked the same way: both targets were rebuilt
rather than saying "up to date".

I'll leave this open as an enhancement to consider, and will be interested to
hear others' thoughts, but at this point I think the current behavior of GNU
make is correct and no changes are needed.

___

Reply to this item at:

  

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

[bug #60281] Directory in directory in $PATH shadows binaries in $PATH

[Paul D. Smith]

Update of bug #60281 (project make):

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


___

Reply to this item at:

  

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

[bug #60557] Built-in rule for preprocessing assembler programs doesn't work as documented

[Paul D. Smith]

Update of bug #60557 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System: POSIX-Based => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

I fixed the default value of PREPROCESS.S to match the documentation.

Thanks for reporting this!

___

Reply to this item at:

  

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

[bug #60777] Command line switch --trace disables -d.

[Paul D. Smith]

Update of bug #60777 (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 #1:

I applied these changes; thanks!

___

Reply to this item at:

  

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

[bug #57778] Stop looking for an included file once found, even if cannot be opened.

[Paul D. Smith]

Update of bug #57778 (project make):

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

___

Follow-up Comment #2:

I've applied this fix, lightly edited for other changes since the patch was
created.

Thanks!

___

Reply to this item at:

  

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

[bug #60795] Document that .PHONY included makefiles are rebuilt but not reread

[Paul D. Smith]

Update of bug #60795 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

I wrote some tests for this and discovered there were some odd corner cases
where included files were not loaded and also no error was thrown.  These
might have been due to changes only in Git.  I added more regression tests,
fixed the problems, and updated the documentation to make clear that phony
targets are treated just like double-colon targets without prerequisites: they
are never used to update included makefiles.

Thanks for the report!

___

Reply to this item at:

  

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

[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

[Paul D. Smith]

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

But my point is that $$ is NOT (intended to be) special to make.  That's why
make doesn't do parentheses matching which it sees it.

In other words, to make this:


bye: $$(hello#world)


is treated the same way as this:


bye: D(hello#world)


for any character "D".  It's not special to make at all and so we don't do
anything special with the parens either.

I don't think it's inconsistent because that's what escaping a character
means: none of its special features are in force.  Personally I think it would
be inconsistent to treat an escaped "$" differently than any other character.

___

Reply to this item at:

  

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

Re: Parallel job instance identifiers?

[David Boyce]

Wait, it is a dumb question. Never mind.

David

On Mon, Sep 6, 2021 at 7:58 AM David Boyce  wrote:

> > One possibility would be for make to write out bytes with values
> 0,1,2,3... then when it gets to 255 start over again ...
>
> I hope this sin't a dumb question, I've never worked with the job server,
> but hy not use the value of the file descriptor from the parent side as the
> token to send down the pipe? Still limited to 255 of course, same wrapping
> problem, but the fd is guaranteed unique and I could imagine cases where
> that data might come in handy for debugging via strace or whatever.
>
> David
>
> On Mon, Sep 6, 2021 at 7:37 AM Paul Smith  wrote:
>
>> On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and
>> discussion for GNU make wrote:
>> > I'm looking for a way to expose a job ID number to the individual
>> > jobs, in a consecutive range from 1-[number of jobs]. Not just
>> > unique numbers, for that we could just use $$ already. The purpose
>> > is to e.g. assign non-overlapping network port numbers when firing
>> > off a number of client/server test scripts in parallel.
>> >
>> > Is there anything that could do this now, exposed as a Make variable?
>>
>> I don't see any way make can provide something like this, at least not
>> using the model it does today.  The current requirement is that each
>> read from the pipe is of exactly 1 byte and there's no way to guarantee
>> a unique value in a single byte of data if there are >256 possible
>> values of course.
>>
>> One possibility would be for make to write out bytes with values
>> 0,1,2,3... then when it gets to 255 start over again: this would give
>> unique values for any -j <= 256 and you'd only have to worry about
>> wrapping for very large values of -j.
>>
>> One reason I'm not excited about this idea is that I've been seriously
>> contemplating switching from the current pipe-based jobserver control
>> method, to using POSIX named semaphores instead (at least as the
>> default).  There is support for these in most systems these days, and
>> it's already how Windows works (with the Windows equivalent).  The
>> advantage here is it's just easier in lots of ways to not have to pass
>> open file descriptors between make invocations.  I could use a named
>> pipe but semaphores are more obviously built for this.  But of course
>> there's no possibility of uniquely identifying a semaphore lock.
>>
>> The other downside of using a semaphore is I was thinking of
>> implementing a "fast fail" feature where as soon as any make in the
>> jobserver domain died all the other makes would stop quickly as well.
>>  This is something people seem to really want.  One way to implement
>> this is to write "error bytes" into the jobserver pipe when we've hit
>> "failure mode"; whenever a make instance reads the "error byte" instead
>> of the "normal byte" it would finish any outstanding jobs then stop.
>>
>> This is pretty straightforward although it's not ideal: make can
>> potentially do a lot of work with its single token without trying to
>> read from the jobserver for example.
>>
>> Of course a single semaphore can't help here.  If we go with "named X"
>> we'll need a directory to hold it; one idea would be to write a
>> "failed" file into that directory that all make's could check for.
>>
>>
>>

[bug #60841] misleading statement in the manual

[Paul D. Smith]

Update of bug #60841 (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 #1:

I made a slightly differently-worded change and applied it, thanks!

It seems like there needs to be a different section on this issue than the one
everything is referencing now (Variables/Recursion) because there are lots of
reasons to export variables that aren't related to recursion.

However I didn't feel up to a major update.

___

Reply to this item at:

  

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

Re: Parallel job instance identifiers?

[David Boyce]

> One possibility would be for make to write out bytes with values
0,1,2,3... then when it gets to 255 start over again ...

I hope this sin't a dumb question, I've never worked with the job server,
but hy not use the value of the file descriptor from the parent side as the
token to send down the pipe? Still limited to 255 of course, same wrapping
problem, but the fd is guaranteed unique and I could imagine cases where
that data might come in handy for debugging via strace or whatever.

David

On Mon, Sep 6, 2021 at 7:37 AM Paul Smith  wrote:

> On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and
> discussion for GNU make wrote:
> > I'm looking for a way to expose a job ID number to the individual
> > jobs, in a consecutive range from 1-[number of jobs]. Not just
> > unique numbers, for that we could just use $$ already. The purpose
> > is to e.g. assign non-overlapping network port numbers when firing
> > off a number of client/server test scripts in parallel.
> >
> > Is there anything that could do this now, exposed as a Make variable?
>
> I don't see any way make can provide something like this, at least not
> using the model it does today.  The current requirement is that each
> read from the pipe is of exactly 1 byte and there's no way to guarantee
> a unique value in a single byte of data if there are >256 possible
> values of course.
>
> One possibility would be for make to write out bytes with values
> 0,1,2,3... then when it gets to 255 start over again: this would give
> unique values for any -j <= 256 and you'd only have to worry about
> wrapping for very large values of -j.
>
> One reason I'm not excited about this idea is that I've been seriously
> contemplating switching from the current pipe-based jobserver control
> method, to using POSIX named semaphores instead (at least as the
> default).  There is support for these in most systems these days, and
> it's already how Windows works (with the Windows equivalent).  The
> advantage here is it's just easier in lots of ways to not have to pass
> open file descriptors between make invocations.  I could use a named
> pipe but semaphores are more obviously built for this.  But of course
> there's no possibility of uniquely identifying a semaphore lock.
>
> The other downside of using a semaphore is I was thinking of
> implementing a "fast fail" feature where as soon as any make in the
> jobserver domain died all the other makes would stop quickly as well.
>  This is something people seem to really want.  One way to implement
> this is to write "error bytes" into the jobserver pipe when we've hit
> "failure mode"; whenever a make instance reads the "error byte" instead
> of the "normal byte" it would finish any outstanding jobs then stop.
>
> This is pretty straightforward although it's not ideal: make can
> potentially do a lot of work with its single token without trying to
> read from the jobserver for example.
>
> Of course a single semaphore can't help here.  If we go with "named X"
> we'll need a directory to hold it; one idea would be to write a
> "failed" file into that directory that all make's could check for.
>
>
>

Re: Parallel job instance identifiers?

[Howard Chu via Bug reports and discussion for GNU make]

Paul Smith wrote:
> On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and
> discussion for GNU make wrote:
>> I'm looking for a way to expose a job ID number to the individual
>> jobs, in a consecutive range from 1-[number of jobs]. Not just
>> unique numbers, for that we could just use $$ already. The purpose
>> is to e.g. assign non-overlapping network port numbers when firing
>> off a number of client/server test scripts in parallel.
>>
>> Is there anything that could do this now, exposed as a Make variable?
> 
> I don't see any way make can provide something like this, at least not
> using the model it does today.  The current requirement is that each
> read from the pipe is of exactly 1 byte and there's no way to guarantee
> a unique value in a single byte of data if there are >256 possible
> values of course.
> 
> One possibility would be for make to write out bytes with values
> 0,1,2,3... then when it gets to 255 start over again: this would give
> unique values for any -j <= 256 and you'd only have to worry about
> wrapping for very large values of -j.

We could change the tokens to be 2 bytes. Individual read/write syscalls
are still guaranteed to be atomic, so there's no danger of interleaving.
The only problem then is ensuring a large enough pipe buffer to avoid
premature blocking.

> The other downside of using a semaphore is I was thinking of
> implementing a "fast fail" feature where as soon as any make in the
> jobserver domain died all the other makes would stop quickly as well.
>  This is something people seem to really want.  One way to implement
> this is to write "error bytes" into the jobserver pipe when we've hit
> "failure mode"; whenever a make instance reads the "error byte" instead
> of the "normal byte" it would finish any outstanding jobs then stop.

It'd be easier just to close the write-side of the pipe, and then all
subsequent read attempts would fail.

> This is pretty straightforward although it's not ideal: make can
> potentially do a lot of work with its single token without trying to
> read from the jobserver for example.
> 
> Of course a single semaphore can't help here.  If we go with "named X"
> we'll need a directory to hold it; one idea would be to write a
> "failed" file into that directory that all make's could check for.

Yes, this is another advantage of using pipes, no special considerations
about namespaces, filesystem or otherwise.

-- 
  -- 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 #61122] Add a .SECONDARY example.

[Dmitry Goncharov]

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

A bit more context about this patch. Recently a person showed me a makefile
with an incorrect use of .SECONDARY. When i asked about this, the person
explained, that there is no example of when .SECONDARY is useful.

___

Reply to this item at:

  

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

[bug #60904] More accurate description of intermediate files

[Paul D. Smith]

Update of bug #60904 (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 #1:

I make slightly different wording to make this explicitly clear.

Thanks!

___

Reply to this item at:

  

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

[bug #61122] Add a .SECONDARY example.

[Dmitry Goncharov]

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

Well, i thought it was obvious that this applies when hello.tsk exists and is
up to date in regards to hello.c and bye.c. But apparently, this is not
obvious. i applied another patch which explicitly states when this applies.

(file #51875)
___

Additional Item Attachment:

File name: sv_61122_doc_secondary_example2.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #61122] Add a .SECONDARY example.

[Paul D. Smith]

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

How can make avoid the rebuild?  You can't link these two object files into a
binary if one or both of them don't exist!

___

Reply to this item at:

  

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

[bug #61122] Add a .SECONDARY example.

[Dmitry Goncharov]

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

File name: sv_61122_doc_secondary_example.diff Size:1 KB
   




___

Reply to this item at:

  

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

Re: Parallel job instance identifiers?

[Paul Smith]

On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and
discussion for GNU make wrote:
> I'm looking for a way to expose a job ID number to the individual
> jobs, in a consecutive range from 1-[number of jobs]. Not just
> unique numbers, for that we could just use $$ already. The purpose
> is to e.g. assign non-overlapping network port numbers when firing
> off a number of client/server test scripts in parallel.
> 
> Is there anything that could do this now, exposed as a Make variable?

I don't see any way make can provide something like this, at least not
using the model it does today.  The current requirement is that each
read from the pipe is of exactly 1 byte and there's no way to guarantee
a unique value in a single byte of data if there are >256 possible
values of course.

One possibility would be for make to write out bytes with values
0,1,2,3... then when it gets to 255 start over again: this would give
unique values for any -j <= 256 and you'd only have to worry about
wrapping for very large values of -j.

One reason I'm not excited about this idea is that I've been seriously
contemplating switching from the current pipe-based jobserver control
method, to using POSIX named semaphores instead (at least as the
default).  There is support for these in most systems these days, and
it's already how Windows works (with the Windows equivalent).  The
advantage here is it's just easier in lots of ways to not have to pass
open file descriptors between make invocations.  I could use a named
pipe but semaphores are more obviously built for this.  But of course
there's no possibility of uniquely identifying a semaphore lock.

The other downside of using a semaphore is I was thinking of
implementing a "fast fail" feature where as soon as any make in the
jobserver domain died all the other makes would stop quickly as well.
 This is something people seem to really want.  One way to implement
this is to write "error bytes" into the jobserver pipe when we've hit
"failure mode"; whenever a make instance reads the "error byte" instead
of the "normal byte" it would finish any outstanding jobs then stop.

This is pretty straightforward although it's not ideal: make can
potentially do a lot of work with its single token without trying to
read from the jobserver for example.

Of course a single semaphore can't help here.  If we go with "named X"
we'll need a directory to hold it; one idea would be to write a
"failed" file into that directory that all make's could check for.

[bug #61122] Add a .SECONDARY example.

[Dmitry Goncharov]

URL:
  

 Summary: Add a .SECONDARY example.
 Project: make
Submitted by: dgoncharov
Submitted on: Mon 06 Sep 2021 02:35:26 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:

Add an example to the manual of how .SECONDARY can be used to avoid
unnecessary rebuilds.




___

Reply to this item at:

  

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