[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #5, bug #47880 (project make):

> The problem is that MAKEFLAGS is only parsed once before all makefiles are
read, and again after all makefiles are read.

So, this all boils down to having make consider changes to MAKEFLAGS
immediately.


> I was hoping to avoid adding a new command line switch.

Well, even with MAKEFLAGS having immediate effect there needs to be a
mechanism to remove the default directories.
Another option is to remove the default directories from make. Is there a
makefile that includes anything from /usr/include or /usr/local/include or
/usr/gnu/include?


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #9, bug #47880 (project make):

> But, maybe it's better to grab that bull by the horns.

>From the user's point of view, it may indeed be better to have a single
interface (MAKEFLAGS), which controls the behavior from the makefile.

> Regarding removing default directories, I wonder what people think of using
something like "-I-" to mean "delete all known include directories up to here
and start over with a fresh set"?

That should work.
Another way is to mimics the shell and use the + sign. +I/usr/include removes
/usr/include.

> It just seems to me that this issue of default include paths is too
minor/rarely problematic to waste an entire command line option on it :).

One trouble of this default is, when your dep files are missing, make does a
fs access per default directory for each missing dep file.
Another trouble is that, as far as i can tell, this default hurts most of the
users to benefit few of them.
However, since Steven reported there are makefile which use this,  i agree,
the default needs to stay.

___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

File name: sv60435_fix.diff   Size:3 KB


File name: sv60435_doc.diff   Size:0 KB


File name: sv60435_tests.diff Size:5 KB




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

i attached 3 patches, the fix, tests and a fix in the doc.
Thanks for your report.

___

Reply to this item at:

  

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

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #11, bug #47880 (project make):

> Can you use this?:
> include $(CURDIR)/foo.mk


This indeed suppresses the lookup.

My opinion is that the users should not have to know this detail. The behavior
should preferably be optimial for the most common scenarios.
Also, most (as far as i can tell) existing makefiles do not do this.


> this might be better considered a question of disabling the search path on a
per-include basis

Is there a need for such flexibility? A command line switch or +I  get the job
done and relieve the users from having to change the makefiles.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #13, bug #47880 (project make):

> > My opinion is that the users should not have to know this detail.

> I didn't realize you were wearing your 'user' hat! 

My bad. By "users" here (and in other places) i meant make users, people who
write makefiles. In other words, when a user writes a makefile he should not
have to know that

depfiles:=$(obj:.o=.d)
include $(depfiles)

is less efficient than

depfiles:=$(obj:.o=.d)
depfiles:=$(addprefix $(CURDIR)/,$(depfiles))
include $(depfiles)

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60595] make doesn't always restart when a makefile is rebuilt

[Dmitry Goncharov]

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

Can you please attach a makefile which reproduces the issue?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

URL:
  

 Summary: Incorrect 2nd expansion of $$< inside a function in
the prerequisite list.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 23 May 2021 02:26:36 PM 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: None
   Fixed Release: None
   Triage Status: None

___

Details:

.SECONDEXPANSION:
hello.x: world.z
hello.x: $$(info <=$$<) ;

Expected output of info is
<=world.z

Actual output of info is
<=

$(info) is used in this example. Other functions cause the same effect.




___

Reply to this item at:

  

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

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

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

File name: sv60659_fix.diff   Size:0 KB


File name: sv60659_test_implicit.diff Size:3 KB
   


File name: sv60659_test_explicit.diff Size:2 KB
   




___

Reply to this item at:

  

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

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

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

Attached tests of explicit and implicit rules and a fix.

___

Reply to this item at:

  

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

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

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

Sure, will do.
Thanks for review.

___

Reply to this item at:

  

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

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

URL:
  

 Summary: Avoid calling strlen repeatedly in a loop.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 30 May 2021 12:08:15 AM 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

___

Details:

Avoid calling strlen repeatedly in a loop in initialize_file_variables.




___

Reply to this item at:

  

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

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

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

File name: sv60699_fix.diff   Size:0 KB




___

Reply to this item at:

  

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

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

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

File name: sv60699_fix.diff   Size:1 KB




___

Reply to this item at:

  

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

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

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

Sure, here is a unified diff.

Rather than attaching diffs, we could submit git branches for review. What do
you think?

___

Reply to this item at:

  

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

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

[Dmitry Goncharov]

URL:
  

 Summary: Introduce "Circular  <-  dependency
dropped." for .EXTRA_PREREQS deps.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 06 Jun 2021 01:33:46 AM 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

___

Details:

Introduce "Circular  <-  dependency dropped." for .EXTRA_PREREQS
dependencies.


$ cat makefile2
hello.x: ; touch $@
hello.x: .EXTRA_PREREQS:=hello.x
$ make -f makefile2
touch hello.x
$

"make: Circular hello.x <- hello.x dependency dropped." is missing.

The message is useful and make prints it in the case of a regular (as opposite
to .EXTRA_PREREQS) circular dependency.





___

Reply to this item at:

  

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

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

[Dmitry Goncharov]

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

With the patch in the attachment the output is

$ make -f makefile2 
make: Circular hello.x <- hello.x dependency dropped.
touch hello.x
$

___

Reply to this item at:

  

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

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

[Dmitry Goncharov]

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

File name: sv_60736_add_avoid_circular_dep_msg.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #60077] Deterministic $@ for grouped targets patch

[Dmitry Goncharov]

Follow-up Comment #5, bug #60077 (project make):

Todd, thank for your contribution.

Your patch is missing second expansion tests.

i observe the following misbehavior.


$ cat makefile
.SECONDEXPANSION:

hello world&: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^))
$(info in recipe @ = $@, @< = $(@<), @^ = $(@^))
$ ~/src/gmake/make/l64/make -f makefile hello
in prereqs @ = world, @< = hello, @^ = hello world
in prereqs @ = hello, @< = hello, @^ = hello world
in recipe @ = hello, @< = hello, @^ = hello world
make: 'hello' is up to date.
$
$
$ cat makefile4
.SECONDEXPANSION:

all: world.z hello.x

%.x %.z&: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^))
$(info in recipe @ = $@, @< = $(@<), @^ = $(@^))
$ ~/src/gmake/make/l64/make -f makefile4 hello.x
in prereqs @ = hello.x, @< = hello.x, @^ = hello.x
in recipe @ = hello.x, @< = hello.x, @^ = hello.x hello.z
make: 'hello.x' is up to date.


Explicit rules are good.
However, you can see during the 2nd expansion of implicit rules @^ expands to
the 1st target, rather than the whole group.

___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

URL:
  

 Summary: Command line switch --trace disables -d.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 13 Jun 2021 09:16:10 PM 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: None
   Fixed Release: None
   Triage Status: None

___

Details:


Commit 7044e0c93 introduced a change which breaks -d when --trace is
specified.

$ cat makefile 
all: ; :
$ ~/src/gmake/make/l64/make -rd --trace
makefile:1: update target 'all' due to: target does not exist
:
$

There is no -d output.




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

File name: sv_60777_fix.diff  Size:0 KB


File name: sv_60777_test.diff Size:0 KB




___

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 #

[Dmitry Goncharov]

URL:
  

 Summary: Parser chokes on second expansion of a prerequisite
with ; o #
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 19 Jun 2021 01:41:58 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Parser chokes on second expansion of a prerequisite with ; o #

$ cat makefile 
MAKEFLAGS+=--warn-undefined-variables
.SECONDEXPANSION:
hello: $$(shell echo world;)
touch $@

bye: $$(hello#world)
touch $@
$ make hello
makefile:7: *** unterminated variable reference.  Stop.
$ make bye
makefile:7: *** unterminated variable reference.  Stop.
$ 


Parser treats ; as a recipe delimiter and # as a comment delimiter.




___

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 #

[Dmitry Goncharov]

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


[comment #0 original submission:]
> Parser chokes on second expansion of a prerequisite with ; o #
> 
> $ cat makefile 
> MAKEFLAGS+=--warn-undefined-variables
> .SECONDEXPANSION:
> hello: $$(shell echo world;)
> touch $@
> 
> bye: $$(hello#world)
> touch $@
> $ make hello
> makefile:7: *** unterminated variable reference.  Stop.
> $ make bye
> makefile:7: *** unterminated variable reference.  Stop.
> $ 
> 
> 
> Parser treats ; as a recipe delimiter and # as a comment delimiter.

(file #51584, file #51585)
___

Additional Item Attachment:

File name: sv_60799_se_semi_fix.diff  Size:4 KB
   


File name: sv_60799_se_semi_test.diff Size:3 KB
   




___

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 #

[Dmitry Goncharov]

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

Yes, it is possible to store special characters in a variable.

i'd not bother fixing this, if not for the fact that make already supports
this input. It is just when second expansion is enabled the parser fails.

i don't think this inconsistency can be described in the manual.

This works fine
hello: $(shell echo world;)

This does not work
.SECONDEXPANSION:
hello: $$(shell echo world;)

___

Reply to this item at:

  

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

[bug #60811] Add long-form aliases for automatic variables

[Dmitry Goncharov]

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

$<, $@, etc are the portable automatic variables. These are standardized by
posix and supported by other unix makes, e.g. sun and ibm makes.
On the other hand, .IMPSRC, etc are not portable.
Introduction of .IMPSRC to gmake cannot improve portability, it can only
hinder it.
Have you considered adding $<, etc to bsd make to improve portability?

In regards to readability, i like this

%.o: %.c
cc -o $@ -c $<

much better than this

%.o: %.c
cc -o $(.TARGET) -c $(.IMPSRC)


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60841] misleading statement in the manual

[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 #60841] misleading statement in the manual

[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 #60904] More accurate description of intermediate files

[Dmitry Goncharov]

URL:
  

 Summary: More accurate description of intermediate files
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 10 Jul 2021 02:53:15 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

"The first difference is what happens if the intermediate file does not exist.
If an ordinary file b does not exist, and make considers a target that depends
on b, it invariably creates b and then updates the target from b. But if b is
an intermediate file, then make can leave well enough alone."

This description can be made more accurate. The manual should explicitly state
that make can leave well enough done, if b is an intermediate file and the
target exists.




___

Reply to this item at:

  

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

[bug #60904] More accurate description of intermediate files

[Dmitry Goncharov]

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

File name: sv_60904_doc_clarify_intermediate.diff Size:1 KB
   




___

Reply to this item at:

  

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

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

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

Thanks for your report, Mike.

make uses file locking on stdout to synchronize output.

int fd = fileno(STDOUT);
fcntl (fd, F_SETLKW, &fl);

After fcntl return make prints its output.

In your case another process has /dev/null locked. With make's stdout
redirected to /dev/null, make blocks in this call to fcntl.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

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

i pushed a fix here
https://github.com/dgoncharov/make/tree/sv_60774_output_sync_deadlock.
This fix does the following.

Lock a temp file to synchronize output.

1. Lock a temp file, rather than stdout, to synchronize output.
Locking stdout prevents make from obtaining the lock when another process has
make's stdout locked. E.g make's stdout is redirected to /dev/null and another
process has /dev/null locked.

2. Pass the file descriptor of this lock file to children through env in
MAKEFLAGS' sync-mutex.

3. Check that a file can be locked before locking it.  With a temp file this
check in acquire_semaphore is not supposed to fail. It won't hurt though.

4. Print a warning message when cannot synchronize output.

Tested this fix on linux. Will be good if anybody could test this fix on
windows.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

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

In your case, Mike, you can either try this fix or find the offending process
with lsof and kill it.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

Follow-up Comment #7, bug #60774 (project make):

The windows code, which passes down the semaphore to children is reused to
pass down the fd on unix.

> The way you propose to reuse the Windows code brings that Windows-specific
stuff back into view.

it is not clear to me what windows specific stuff you mean.
Let us go over it?

record_sync_mutex reads the value of the fd from the env variable. Reused
between unix and windows.

prepare_mutex_handle_string stores the value of the fd in makeflags. Reused
between unix and windows.

create_mutex is modified to return the value of the semaphore. Still windows
specific.

mutex_handle - global variable. Removed. Instead of mutex_handle and
sync_handle, there is only sync_handle.



___

Reply to this item at:

  

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

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

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

File name: sv_60774_output_sync_deadlock_fix.diff Size:6 KB
   




___

Reply to this item at:

  

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

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

Follow-up Comment #9, bug #60774 (project make):

i was able to test on windows and attached a proposed patch.
The patch does what is described in update 3.

___

Reply to this item at:

  

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

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

[Dmitry Goncharov]

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

File name: sv_60774_output_sync_deadlock_fix2.diff Size:6 KB
   




___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

URL:
  

 Summary: Enhance implicit rule search logging
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 15 Aug 2021 04:11:25 AM 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: Any
   Fixed Release: None
   Triage Status: None

___

Details:

Enhance implicit search logging.

Consider this rule
%.o: %.c; $(CC) -o $@ -c $<

When the user wants to make hello.o and hello.c is missing, make gives the
following diagnostics.

$ ls
makefile
$ cat makefile
%.o: %.c; $(CC) -o $@ -c $<
$ ~/src/gmake/make/m64/make -R --debug=implicit hello.o |tail +9
Updating goal targets
 File 'hello.o' does not exist.
 Looking for an implicit rule for 'hello.o'.
 Trying pattern rule with stem 'hello'.
 Trying implicit prerequisite 'hello.c'.
 Trying pattern rule with stem 'hello'.
 Trying implicit prerequisite 'hello.c'.
 Looking for a rule with intermediate file 'hello.c'.
  Avoiding implicit rule recursion.
 No implicit rule found for 'hello.o'.
Must remake target 'hello.o'.
make: *** No rule to make target 'hello.o'.  Stop.
$

The bottom line in this diagnostics is the "No rule found" message.
While the issue is that hello.c is missing.
And the user stares at the makefile and says
"How cannot make find the rule? Here it is."

Preferably make should tell which rule it is trying and why it is rejecting
it
and which prerequisite make is trying and what the outcome is.




___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

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

File name: sv_61042_implicit_rule_search_logging.diff Size:13 KB
   




___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

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

sv_61042_implicit_rule_search_logging.diff has the following

Changes in the implicit rule search logging:
1. The messages which refer to a rule print the first line
(the targets and prerequisites) of the rule.
2. A new message tells when a rule is rejected, along with the reason.
3. The 'Looking for an implicit rule...' message is printed for every
prerequisite, rather than the top level target only.
4. "Trying harder" message is printed, when intermediate prerequisites are
allowed.
5. The 'No rule found...' and 'Found implicit rule...' messages are printed
for
every prerequisite, rather than the top level target only.
6. "Ought to exist...", "Found..." or "Not found..." message is printed for
each prerequisite.

This is the diagnostics of the same example above with enhanced logging.

$ ~/src/gmake/make/l64/make -R --debug=implicit hello.o |tail +9
Updating goal targets
 File 'hello.o' does not exist.
 Looking for an implicit rule for 'hello.o'.
 Trying pattern rule '%.o: %.c' with stem 'hello'.
 Trying implicit prerequisite 'hello.c'.
 Not found 'hello.c'.
 Trying harder.
 Trying pattern rule '%.o: %.c' with stem 'hello'.
 Trying implicit prerequisite 'hello.c'.
 Looking for a rule with intermediate file 'hello.c'.
  Avoiding implicit rule recursion for rule '%.o: %.c'.
  No implicit rule found for 'hello.c'.
 Rejecting rule '%.o: %.c' due to impossible prerequisite 'hello.c'.
 No implicit rule found for 'hello.o'.
Must remake target 'hello.o'.
make: *** No rule to make target 'hello.o'.  Stop.

___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

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

File name: sv_61042_reuse_rule_name_for_dash_p.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

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

sv_61042_reuse_rule_name_for_dash_p.diff reuses rule->name for printing the db
under -p.

___

Reply to this item at:

  

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

[bug #61069] Document phony order-only prerequisites.

[Dmitry Goncharov]

URL:
  

 Summary: Document phony order-only prerequisites.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 21 Aug 2021 09:17:13 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:

In a recent conversation a user complained, that it is unclear whether a
target that depends on a phony order-only prerequisite is supposed to be
rebuilt when the prerequisite exists.




___

Reply to this item at:

  

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

[bug #61069] Document phony order-only prerequisites.

[Dmitry Goncharov]

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

File name: sv_61069_document_orderonly_beats_phony.diff Size:0 KB
   




___

Reply to this item at:

  

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

[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/

[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/

[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.

[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 #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 #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

[Dmitry Goncharov]

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

There was a recent discussion about this. See
https://savannah.gnu.org/bugs/?60774 and the mailing list.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

[Dmitry Goncharov]

Follow-up Comment #5, bug #52922 (project make):

> Maybe this enhancement (using a separate lock file for submakes that are
redirected) is something that simply won't be supported on those systems as
the effort is not worth the reward.

This confuses users on linux as well.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

[Dmitry Goncharov]

Follow-up Comment #10, bug #52922 (project make):

> I considered fixing that in FreeBSD, but I'm running build farm stuff across
a bunch of OSes that all have this problem hence desire to fix it here.


Gentlemen, can you please describe the state of affairs in the bsd world in
regards to gnu make? Is there a number of ports which have gnu make specific
makefiles? Is there a number of ports which have portable makefiles and you
prefer to build them with gnu make?
In other words, what causes you to use gnu make to build bsd ports?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

URL:
  

 Summary: A regression prevents generation of missing included
dependency files.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 26 Sep 2021 02:34:37 PM 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: None
   Fixed Release: None
   Triage Status: None

___

Details:

7c4e6b0299774280e3a93060c70c661f459aaf40 introduced a change in main.c, among
others.
This change causes make to exit with an error message when a rule that matches
an included file does not create the file.
This change is good when the included file is indeed intended to be created.
However, this change is a regression when the included file is not intended to
be created, as in the case of generated dependency files.
E.g.


hello.o: hello.d; touch $@ $<
hello.d:;
include hello.d


In this makefile the rule 'hello.d:;' is not intended to create 'hello.d'.
Instead, when 'hello.d' is missing make runs 'hello.d:;' rule and imagines
'hello.d' was updated and then proceeds to create 'hello.o' and thus generates
'hello.d' as a byproduct of 'hello.o' generation.




___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

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

File name: sv_61226_no_build_on_missing_includes.diff Size:2 KB
   


File name: sv_61226_no_build_on_missing_includes_test.diff Size:3 KB
   




___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

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

This is an example of the failure

$ ls
makefile
$ cat makefile 
hello.o: hello.d; touch $@ $<
hello.d:;
include hello.d
$ make
makefile:3: hello.d: No such file or directory
$ echo $?
2


___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

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

i agree, this is a special case.
imo, empty vs not empty is okay for make to consider, given that make manual
documents this special behavior when the recipe or prerequisites are empty and
the file is missing.

This is in sharp contract with the other case, when there is a recipe and the
recipe fails to create the file. imo, it is correct for make to fail that
case.

Would it be acceptable if we could retain the previous fix and allow for this
special case?

___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

Follow-up Comment #5, bug #61226 (project make):

> When you say the special behavior do you mean the section "Rules without
Recipes or Prerequisites"?

exactly


> I think that text is a little misleading.  There's actually nothing magical
about having no recipe or an empty recipe here, as best as I can remember. 
Make doesn't check for this.  Even if you provide a recipe for a force target
it will still behave the same as it would without a recipe, as long as the
recipe doesn't actually create the force target.

There is a difference between the implementation and the text in the manual.
Given that the implementation is bound by backward compatibility, i think the
text needs to be updated. Even though, this may not be what the original
authors intended.

There is also this statement in "3.3 Including Other Makefiles"
"...after it has tried to find a way to remake a makefile and failed, will
make diagnose the missing makefile as a fatal error. "

This statement says a missing makefile is a fatal error, regardless of whether
the rule returned success. Looks like this part of the manual needs to be
updated too.

> My current thinking on this is we should revert this part of the fix, but
leave the original part.

Do you mean keep the change in remake.c?

> Maybe the thing to do is, if we detect this situation we can emit a warning
message that users should change their makefiles to use "-include" instead of
"include" which would avoid that warning.  Then in a few releases we could put
back this change where make would fail if included files weren't built.

i am attaching another patch with a warning. If this patch is good, then we'll
need to update the tests.
This warning in the attached patch is quite verbose, because it is printed for
every missing .d file.

___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

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

File name: sv_61226_no_build_on_missing_includes.diff Size:1 KB
   




___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

Follow-up Comment #6, bug #61226 (project make):

It is disturbing that the warning is printed each time a .d file is missing.
In other words, make prints a warning in an everything goes as planned
situation, like a clean build. Switching to -include robs the user of a useful
message, should there be a real issue.

___

Reply to this item at:

  

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

[bug #61328] elide the distinction between "dir" and "dir/"

[Dmitry Goncharov]

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

> However, since "foo/" is illegal for anything but a directory it seems
harmless to assume directory. This special case could also be made to apply
exclusively to order-only prerequisites which is where directory dependencies
should be anyway.

It is not clear (atleast to me) what special behavior you mean. Do you mean
that make assumes that any order-only prerequisite is a directory and compares
'foo' as equal to 'foo/', as long as 'foo' is order-only?


Why don't you append a slash?


$(target): $$(@D)/


___

Reply to this item at:

  

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

[bug #61328] elide the distinction between "dir" and "dir/"

[Dmitry Goncharov]

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

> my argument is that it can assume paths ending in the path separator are
directories since they can't be anything else:

This assumption looks reasonable.
What change in behavior do you think is appropriate with this assumption?

___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

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

Another scenario that i noticed, when this enhanced logging helps, is when the
source file is present, but vpath is incorrect.
E.g. vpath %.cpp %.c $(srcdir).
Again make ignores the rule, because it cannot find the source file, but gives
no indication of why it ignores the rule. The new logging prints "Not found
''.".

___

Reply to this item at:

  

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

[bug #61226] A regression prevents generation of missing included dependency files.

[Dmitry Goncharov]

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

> > Switching to -include robs the user of a useful message, should there be a
real issue.

> I'm not sure what this means: in what situation do we lose a useful
message?

-include robs the user of a not readable or corrupted .d file, even though
user's intervention is required.

i think, hand written included makefiles require different error handling than
generated .d files.

A missing hand written makefile is an error. The user has the choice of
'include' vs '-include' as you described above. I agree with that logic.

On the other hand, a missing .d file (or any other included makefile generated
by a rule) is not an error. It is simply a clean build.

i think, make should not print a warning when a .d file is missing. make
should proceed and create the missing file. However, when .d is present, but
make cannot include it, then make should print an error and stop.


The traditional make behavior, which is still in 4.3 is exactly this.
i think, we should retain this behavior.


in regards to the change in main.c see the following possibilities

1. Revert the change in main.c.
2. Modify the change in main.c to allow for missing .d files, but print an
error and stop in the other cases.
3. Modify the change in main.c to print a warning and continue.

i like option 2, which is what the first patch does. You correctly observed
that this will break any rule that has prerequisites and a recipe and fails to
generate the file and returns 0.
This boils down to that difference between the implementation and the manual.
Do you want to update the manual to match the implementation or vice versa?

___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

Follow-up Comment #7, bug #61042 (project make):

There are 2 situations when implicit rule lookup takes this short cut.

1.

hello.tsk: hello.o
%.tsk: %.o; touch $@


and

2.

hello.tsk:
%.tsk: %.o; touch $@
hello.o:



There are 2 if branches in implicit.c

This branch handles the case 1 described above.


for (expl_d = file->deps; expl_d != 0; expl_d = expl_d->next)
if (streq (dep_name (expl_d), d->name))
  break;
if (expl_d != 0)
{
  (pat++)->name = d->name;
  continue;
}


and

This branch handles the case 2 described above.



f = lookup_file (d->name);
if (f /* || ((!dep->changed || check_lastslash) */
  || file_exists_p (d->name))
{
  (pat++)->name = d->name;
  continue;
}


This patch has both if branches combined to handle both cases, because the
handling is the same.
The conflict was introduced by this fix to set f->is_explicit.
Let me merge master onto my branch and resubmit.

___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

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

Merged master to my branch and resolved the conflict in patch
 sv_61042_implicit_rule_search_logging2.diff.

The same change is also available here 
g...@github.com:dgoncharov/make.git
on branch
sv61042_enhance_implicit_search_logging.

(file #52115)
___

Additional Item Attachment:

File name: sv_61042_implicit_rule_search_logging2.diff Size:12 KB
   




___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #12, bug #48643 (project make):

Let us say hello.c is missing, hello.f is present in the filesystem and
consider the following example

Example 1.

all: hello.tsk
%.tsk: %.c; $(info $@ from $<)
%.tsk: %.f; $(info $@ from $<)
unrelated: hello.c


The current behavior is to choose rule '%.tsk: %.c' because 'hello.c' is
mentioned explicitly on an unrelated rule.
The desired behavior is to skip '%.tsk: %.c' rule and choose '%.tsk: %.f'
rule.

This desired behavior alone could be achieved by eliminating ought-to-exist.

However, let us consider the following example which demonstrates that
ought-to-exist concept has to stay.

Example 2.

all: hello.tsk
hello.tsk: hello.c
%.tsk: %.c; $(info $@ from $<)
%.tsk: %.f; $(info $@ from $<)


When make considers rule '%.tsk: %.c' make discovers that hello.c is an
explicit prerequisite of the current target hello.tsk.  This qualifies hello.c
as ought to exist and tells make to choose this rule.  Regardless of whether
hello.c is present in the filesystem.  Even if hello.c is missing and hello.f
is present make still has to choose '%.tsk: %.c' rule, rather then '%.tsk:
%.f' rule, because the user specified hello.c as an explicit prerequisite of
hello.tsk.


On the other hand, when hello.c is an explicit prerequisite of an unrelated
rule (as in example 1), then the current definition of ought-to-exist is too
broad and causes an unrelated rule to be chosen.

i think, a good change is to restrict ought-to-exist as this

"If a file name is mentioned in the makefile as a target or as an explicit
prerequisite of the current target, then we say it ought to exist."


This will exclude unrelated rules in example 1, but still allow the intended
use case of ought-to-exist presented above in example 2.

However, this change of the definition of ought-to-exist and the related
change in the implementation will break the makefiles that depend on the old
behavior.

Example 3.

all: hello.tsk
%.tsk: %; $(info $@ from $<)
unrelated: hello


In this example rule '%.tsk: %' is chosen to build hello.tsk, because 'hello'
is mentioned explicitly on an unrelated rule.

We need to solve both
1. Skip unrelated rules.
and
2. Be compatible with makefiles that depend on unrelated rules.

The simplest and most reliable solution that meets both of these goals, i have
found is the following

1. Change the definition of ought-to-exist as described above.
2. Search according to the new definition of ought-to-exist. This will skip
all unrelated rules and achieve the desired effect.
3. If no rule is found, then search according to the old definition of
ought-to-exist. This allows makefiles which depend on the old definition of
ought-to-exist to keep working.

Notes about this proposed solution
1. This solution does not attempt to build the prerequisite in order to decide
if it can be used. I explored possible solutions which build the prerequisite
and came to the conclusion, the right behavior is to not attempt to build
one.

2. Compatibility search (step 3 in the algorithm above) should only be
performed, if the initial search finds such a prerequisite that is explicitly
mentioned on an unrelated rule. This ensures that if the makefile does not
have such a prerequisite, then no compatibility search is performed.

3. We could introduce a warning when compatibility search is performed and
advice the user to fix the makefile.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

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

File name: sv48643_test.diff  Size:10 KB


File name: sv48643_doc.diff   Size:1 KB


File name: sv48643_fix.diff   Size:8 KB


File name: sv48643_news.diff  Size:0 KB




___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #13, bug #48643 (project make):

Added 4 patches. fix, test, doc and news.
The same changeset can be found in repo g...@github.com:dgoncharov/make.git on
branch sv48643_retry_compat_rules.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #15, bug #48643 (project make):

> Are you saying that this also should be the correct behaviour? 

I now realize, that inadequate description of example 3 was provided and
caused misunderstanding.
Let me provide a more verbose description.

Make has to do both skip unrelated rules and stay compatible with the
makefiles that depend on unrelated rules.


Example 3 is depends on unrelated rules. Make-4.3 successfully builds example
3 and the fix has to take care to keep building it.

Let us repeat example 3 here.

Example 3.

all: hello.tsk
%.tsk: %; $(info $@ from $<)
unrelated: hello


In example 3 rule '%.tsk: %' is chosen to build 'hello.tsk', because 'hello'
is mentioned explicitly on an unrelated rule.  Builtin rule '%: %.f' is chosen
to build 'hello' from 'hello.f', because 'hello.f' exists.  The chain is
hello.tsk <- hello <- hello.f.

Patch-v2 fails example 3.
Patch-v1 has code to handle this use case and is capable of building example
3.

However, i believe, there are other issues with patch-v1, described below.

Let us say hello.f is present in the filesystem and consider the following
example.

Example 4.

all: hello.tsk
%.tsk: %; $(info hello.tsk)
%: %.f; $(info hello.f)


Make looks for a rule to build 'hello.tsk' and considers '%.tsk: %'.  '%'
expands to 'hello'. There is no file 'hello' and 'hello' does not qualify as %
ought-to-exist.  There is rule '%: %.f' which can be used to build 'hello'
from 'hello.f', because 'hello.f' exists.  However, make rejects rule '%:
%.f', because 'hello' is an intermediate.
The manual does not allow match-anything rules to build intermediates for
performance reasons.
The original make authors made this (good imo) design choice and put this
restriction in the manual. See "10.5.5 Match-Anything Pattern Rules.".
Both make-4.3 and dgfix fail example 4.

Patch-v1, however, allows match-anything rules to build intermediates.
Patch-v1 causes makes to build 'hello' from '%: %.f' and then 'hello.tsk' from
'hello.'
This is the major issue with patch-v1.
This is not a bug fix any longer. This is a new and an expensive undesired
feature, accidentally sneaked into make.

If patch-v1 is applied and released, then users will start writing makefiles
which depend on this feature. This will slow down make, including for those
users who do not even use this feature. Once this feature is released, it will
be very difficult to undo.

Another issue with patch-v1 is that we don't know which uses cases it fails to
be compatible with.
Let us say hello.c and hello.tsk are missing and consider the following
example.

Example 5.

all: hello.tsk
%.tsk: %.c; gcc -o $@ $<
.DEFAULT:; echo 'int main() {}' > $@
unrelated: hello.c


Here, make chooses rule '%.tsk: %.c' to build hello.tsk, because hello.c is
mentioned on an unrelated rule.  Make then finds the default rule to build
hello.c. Both make-4.3 and dgfix support example 5. Patch-v1 fails example 5.

I attempted to modify the search algorithm to support all the possible use
cases and concluded that the most reliable and the simplest is the algorithm
that performs compatibility search, presented above.
We can reason that the compatibility search supports all uses cases that
make-4.3 supports, because compatibility search is the same as the current
search of make-4.3.


> here's only a difference between the implementations when the Makefile isn't
going to work anyway

i hope, this demonstrates that there are other differences.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #17, bug #48643 (project make):

Thank you, Steven.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

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

File name: sv48643_fix2.diff  Size:8 KB


File name: sv48643_test2.diff Size:12 KB




___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #18, bug #48643 (project make):

Attached sv48643_fix2.diff and sv48643_test2.diff.

sv48643_test2.diff contains two new tests compared to sv48643_test.diff..
These new tests require that compatibility search builds intermediates.

sv48643_fix2.diff has two changes compared to sv48643_fix.diff.
Change 1: allow compatibility search to build intermediates. This is needed
for the new tests to pass.
Change 2: optimize compatibility search by keeping prerequisites explicitly
mentioned on unrelated rules as "possible".

___

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 #

[Dmitry Goncharov]

Follow-up Comment #5, 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.

Sure, we can adopt this stance and say no parentheses matching for $$. i am
not sure this behavior is the most useful make can offer.

Do you think this behavior is consistent from the user's point of view?

This works fine

.SECONDEXPANSION:
hello: $$(shell echo world); touch $@


This does not work

.SECONDEXPANSION:
hello: $$(shell echo world;); touch $@


You are right that the proposed patch adds parentheses matching and thus makes
$$ special. As far as i understood, you have a concern about making $$
special?


___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #20, bug #48643 (project make):

Thank you, Paul.

The user may not realize that their makefile relies on compatibility search
and the related performance penalty.
Do you think it is appropriate to print a message when make begins
compatibility search to let the user know?

___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

Follow-up Comment #10, bug #61042 (project make):

Thank you, Paul.

Does the leading underscore in rule->_defn has a special meaning, follow gnu
make convention or similar?

___

Reply to this item at:

  

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

[bug #61042] Enhance implicit rule search logging

[Dmitry Goncharov]

Follow-up Comment #12, bug #61042 (project make):

> I used it because I wanted to mark that data member as being "private" in
the sense that it shouldn't be used directly by other parts of the code;
instead the get_rule_defn() function should always be called to retrieve that
value.

Good to know. i'll follow this convention.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #22, bug #48643 (project make):

> If I add a note when we start the compatibility check, it shows up here
(obviously we'd pick a more informative note if we added this):
...
> I guess it's appropriate here but it seemed odd to me.

i also think, it is appropriate here.
Does the message seem better if it says e.g.


"No implicit rule found to build 'hello.o'.
Trying compatibility search due to explicit prerequisite 'hello.tsk'."

?

> I wonder how many existing build systems would trigger this note?

When this behavior was modified in 2009 there were 5 bug reports listed in
https://savannah.gnu.org/bugs/?17752.

i am less concerned that existing makefiles, which rely on compatibility
search, trigger this new message.

My main concern is the makefiles which never relied on the old definition of
ought-to-exist. Those makefile (or brand new ones) can accidentally fall
victims of compatibility search, because compatibility search is enabled by
default and it is silent.

When i maintain a makefile, i definitely do not want to depend on
compatibility search and would appreciate if make gave me a hint whenever such
dependency is introduced.

Such a message could be enabled by default.

Alternatively, we can introduce a flag e.g. '--warn-compatibility-search' or
'--disable-compatibility-search'.
i like 'disable' better than 'warn', because 'disable' would cause make to
exit with an error on the 1st failed prerequisite. 'Warn', on the other hand,
would cause make to print the same message multiple times (once for every
prerequisite).
i also suspect, that most users won't enable such flag, should we add one.


___

Reply to this item at:

  

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

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

[Dmitry Goncharov]

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

i agree that the makefile in question is incorrect.
i don't think the patch should be applied. i should not have provided the
patch to begin with.

i'd just gave the 'a.mk: b' rule a proper recipe which builds 'a.mk', rather
than an empty recipe.
With an empty recipe when 'b' is present, but 'a.mk' is missing, 'a.mk' won't
be created.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #23, bug #48643 (project make):

Yet another option is to have compatibility search disabled by default and
introduce flag '--enable-compatibility-search'.
This is a good choice going forward, because we really don't want new
makefiles to rely on compatibility search.
This choice will require those users who rely on compatibility search to
either modify the makefile to not rely on compatibility search or to add
--enable-compatibility-search to makeflags.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #25, bug #48643 (project make):

Let us list the options
1. keep compat search enabled by default and silent.
2. introduce a warning message when make begins compat search.
3. introduce a flag to disable compat search.
4. have compat disabled by default and introduce a flag to enable it.

1 is the current state of the code in master. i think, this is releasable.

2 is the same as 1 plus a warning message. i think, this message a good hint
and hopefully will drive users away from compat search.

3 requires that users specify the flag. If the flag is specified in MAKEFLAGS,
then it will be inherited by recursive makes, which may or may not be
desired.

4 is backward incompatible. This choice forces the users to modify the
makefiles that depend on the old definition of ought-to-exist. Given that the
users have to modify the makefile, they can as well fix the rules to avoid
this dependency on the old def of ought-to-exist. This ability to fix the
rules makes a flag to enable compat-search redundant.

___

Reply to this item at:

  

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

Re: [PATCH] doc: note that $(wildcard) is implemented in terms of glob(3)

[Dmitry Goncharov]

On Fri, Dec 3, 2021 at 9:19 AM Ævar Arnfjörð Bjarmason  wrote:
>
> The $subject isn't strictly true, as the it's implemented in terms of
> MatchFirst() on Amiga, but that's obscure enough to not be noted in
> the manual

Then the manual will be lying to the users of amiga, right?

> and in any case the tests added in 0d366b66 (* Added the
> test suite to the main distribution., 1999-09-14) show that the output
> is sorted on all platforms GNU make has been tested on.

The tests don't verify that the output is sorted. It is just that this
input in the test results in this output.
Implementation may change (e.g. for performance reasons) to avoid
sorting and the tests will be updated accordingly.

Furthermore, a different input can result in not sorted output.

$ ls
1  2  3  makefile
$ cat makefile
files:=$(wildcard 2 1 3)
all:; $(info $(files))
$ make
2 1 3
make: 'all' is up to date.
$


> Aside: I found it difficult to figure out how to submit patches to
> this project.

https://savannah.gnu.org/bugs/?group=make&func=additem

regards, Dmitry

[bug #61623] Add a startup optimizaton hint to the manual.

[Dmitry Goncharov]

URL:
  

 Summary: Add a startup optimizaton hint to the manual.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 05 Dec 2021 09:56:47 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 patch in the attachment adds a hint of how to avoid implicit search for a
rule to remake the makefile.




___

Reply to this item at:

  

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

[bug #61623] Add a startup optimizaton hint to the manual.

[Dmitry Goncharov]

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

File name: sv61623_doc.diff   Size:1 KB




___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #27, bug #48643 (project make):

i figured this change is still incomplete. There is a case when make marks
this almost-ought-to-exist prerequisite as intermediate incorrectly.

Let us say hello.tsk exists and hello.x is missing and consider

Example 6.


all: hello.tsk
%.tsk: %.x; touch hello.tsk
%.x: ;
unrelated: hello.x


make-4.3 does the following
1. Tries rule '%.tsk: %.x' for 'hello.tsk'.
2. Tries prerequisite 'hello.x'.
3. Notices that 'hello.x' is mentioned explicitly on an unrelated rule.
4. Considers 'hello.x' ought-to-exist.
5. Chooses rule '%.tsk: %.x' for 'hello.tsk'. Notice, make-4.3 has not tried
'hello.x' as an intermediate and thus 'hello.x' does not have intermediate
flag set.
6. Remakes 'hello.tsk', because 'hello.x' is not intermediate.

master does the following
1. Tries rule '%.tsk: %.x' for 'hello.tsk'.
2. Tries prerequisite 'hello.x'.
3. Notices that 'hello.x' is mentioned explicitly on an unrelated rule.
4. Considers that 'hello.x' does not qualify as ought-to-exist.
5. Tries 'hello.x' as an intermediate.
6. Chooses rule '%.x' for 'hello.x'.
7. Sets intermediate flag for 'hello.x'.
8. Chooses rule '%.tsk: %.x' for 'hello.tsk'.
9. Fails to remake 'hello.tsk', because 'hello.x' is intermediate.

Please find a fix in sv48643_exp_preqreq_is_not_interm.diff and tests in
sv48643_exp_preqreq_is_not_interm_tests.diff.


___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

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

File name: sv48643_exp_preqreq_is_not_interm_tests.diff Size:4 KB
   


File name: sv48643_exp_preqreq_is_not_interm.diff Size:1 KB
   




___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

Follow-up Comment #28, bug #48643 (project make):

Let us consider Example 7.


all: hello.tsk
%.tsk: hello.x; $(info $@)
%.x:; $(flags)
hello.x: flags:=true


Here 'hello.x' has a target specific variable 'flags' with value 'true'.
Setting a target specific variable causes make to enter 'hello.x' to the
database as a prerequisite. Implicit search then finds 'hello.x' in the
database and knows that 'hello.x' is mentioned explicitly.

make-4.3 would at that point consider 'hello.'x as ought-to-exist.
master figures out that 'hello.x' is not a target and is not a prerequisite of
the current target 'hello.tsk'. master therefore decides that 'hello.x' does
not qualify as ought-to-exit. master proceeds and finds that 'hello.x' can be
built as an intermediate by rule '%.x:;'.

At that point make needs to init the file in the database from the
intermediate (cmds, deps, etc) and it incorrectly wipes out the target
specific variables of the file already stored in the database.

Previously this didn't not matter, because 4.3 treats 'hello.x' as
ought-to-exist and does not even attempt to built it as an intermediate.
Now this matters.
Please find a fix in the attached patch
sv48643_preserve_target_specific_vars_of_interm.diff
and related tests in
sv48643_preserve_target_specific_vars_of_interm_test.diff.

___

Reply to this item at:

  

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

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

[Dmitry Goncharov]

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

File name: sv48643_preserve_target_specific_vars_of_interm_test.diff Size:2 KB
   


File name: sv48643_preserve_target_specific_vars_of_interm.diff Size:1 KB
   




___

Reply to this item at:

  

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

Re: .SECONDEXPANSION problems

[Dmitry Goncharov]

On Sun, Dec 12, 2021 at 2:15 PM Paul Smith  wrote:
> Did something happen when it stopped working, like you updated to a
> different version of GNU make?

i bet this make is built from the current git.

> Can you create a small, self-contained example that shows the problem you're 
> seeing?

i don't think this is related to second expansion. This is about
target specific variables of intermediate files.
here is an example which reproduces the problem.

all: hello.tsk
%.tsk: hello.x; $(info $@)
%.x:; $(flags)
hello.x: flags:=true

i posted a detailed description here
https://savannah.gnu.org/bugs/?48643#comment28.

On Thu, Dec 9, 2021 at 6:26 AM Gisle Vanem  wrote:
> My problem is that 'EXTRA_CFLAGS' is NOT picked up by
> the above pattern compile rule when the .SECONDEXPANSION
> rule is used. This used to work for sure.

Thanks for your report.
If you need make from git you should apply
https://savannah.gnu.org/bugs/download.php?file_id=52483
and
https://savannah.gnu.org/bugs/download.php?file_id=52489

regards, Dmitry

Re: Compilation error with GCC

[Dmitry Goncharov]

On Sun, Dec 19, 2021 at 1:51 PM Mohammad Akhlaghi  wrote:

> The configuration went nicely, however, during the compilation it
> crashed with the attached error.

i think, Jouke provided patches to workaround this warning.
You can pass a flag to gcc to not treat warnings as errors.
e.g.
$ make CFLAGS=-Wno-error


regards, Dmitry

Re: escaped newline in macro expansion in command line

[Dmitry Goncharov]

On Fri, Dec 24, 2021 at 6:30 PM Humm  wrote:
> That’s the argument I’m making.

Humm, in the following example do you want N and M to expand to
different values? If yes, can you please tell us about your use case
where such behavior is needed?

.POSIX:
M=word
N=${M:word=a\
b}
all:; echo ${N} ${M:word=a\
b}

i tested gmake, bmake, sun make and aix make.
gmake and bmake both replace the newline with a space and pass 'a b a
b' to the shell.
sun make fails to find the closing brace and exits with an error message.
aix make removes the newline and passes 'a b ab' to the shell.

in the following example
all:; echo 'a\
b'
gmake and sun make both pass 'a\
b' to the shell.
bmake passes 'a b' to the shell.
aix make passes 'ab' to the shell.

i think gnu make's behavior is correct. Otherwise, variable expansion
becomes context dependent and who needs that complication?
Gnu make manual is quite explicit
5.1.2 says
"Variable and function references in recipes have identical syntax and
semantics to references elsewhere in the makefile."

If we can agree, then i'll file a request to opengroup to explicitly
state that this

"When an escaped  is found in a command line in a makefile,
the command line shall contain the , the , and the
next line, except that the first character of the next line shall not
be included if it is a ".

takes place after variable expansion.

regards, Dmitry

Re: Segafult while running make(1) from /lib/init/rc with -j

[Dmitry Goncharov]

On Thu, Jan 6, 2022 at 2:13 PM Alejandro Colomar (man-pages)
 wrote:
>  I could try to write a simpler Makefile

That would be good. We need to be able to reproduce the crash.

regards, Dmitry

Re: .SILENT: clobbered by .SILENT: with_target

[Dmitry Goncharov]

On Tue, Jan 11, 2022 at 3:50 PM Britton Kerin  wrote:
> It looks like the .SILENT: with a recipe clobbers the .SILENT:
> without

Consider the following

hello.tsk:
hello.tsk: hello.h
hello.tsk: hello.o; $(CC) -o $@ $<


Here, hello.tsk is the default goal and it depends on hello.o and hello.h.
Multiple rules can provide different prerequisites to the same target.
The above is equivalent to
hello.tsk: hello.o hello.h
You can see that this example mimics your .silent example.
Your makefile provided a prerequisite to .SILENT. Make then knows that
.SILENT has a prerequisite.

regards, Dmitry

[bug #61805] .ONESHELL causes quoting in .SHELLFLAGS to not work as expected.

[Dmitry Goncharov]

URL:
  

 Summary: .ONESHELL causes quoting in .SHELLFLAGS to not work
as expected.
 Project: make
Submitted by: dgoncharov
Submitted on: Thu 13 Jan 2022 12:53:17 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: None
   Fixed Release: None
   Triage Status: None

___

Details:

A user reported the following

.ONESHELL causes quoting in .SHELLFLAGS to not work as expected.

$ cat Makefile
.ONESHELL:
SHELL = /usr/bin/perl
.SHELLFLAGS = -w -E 'use warnings FATAL => "all";' -E
all:
print 'it works'
$ make all
print 'it works'
Can't find string terminator "'" anywhere before EOF at -e line 1.
make: *** [Makefile:5: all] Error 255
$

Without .ONESHELL: the above works as expected.

The original bug report is here
https://lists.gnu.org/archive/html/bug-make/2022-01/msg00024.html.




___

Reply to this item at:

  

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

[bug #61805] .ONESHELL causes quoting in .SHELLFLAGS to not work as expected.

[Dmitry Goncharov]

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

There is a dedicated piece of code in job.c for oneshell. This dedicated piece
of code tokenizes the contents of shellflags by white space.


___

Reply to this item at:

  

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

[bug #61805] .ONESHELL causes quoting in .SHELLFLAGS to not work as expected.

[Dmitry Goncharov]

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

The patch in the attachment has a fix against the current master and a test.

(file #52654, file #52655)
___

Additional Item Attachment:

File name: sv61805_test.diff  Size:0 KB


File name: sv61805.diff   Size:1 KB




___

Reply to this item at:

  

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

Re: .ONESHELL causes quoting in .SHELLFLAGS to not work as expected

[Dmitry Goncharov]

On Tue, Jan 11, 2022 at 3:53 PM Britton Kerin  wrote:
>
> $ cat Makefile
> .ONESHELL:
> SHELL = /usr/bin/perl
> .SHELLFLAGS = -w -E 'use warnings FATAL => "all";' -E
> all:
> print 'it works'
> $ make all
> print 'it works'
> Can't find string terminator "'" anywhere before EOF at -e line 1.
> make: *** [Makefile:5: all] Error 255
> $


Thank you for your report.
I opened https://savannah.gnu.org/bugs/index.php?61805 and attached a fix.

regards, Dmitry

Re: escaped newline in macro expansion in command line

[Dmitry Goncharov]

On Fri, Jan 7, 2022 at 11:32 AM Dmitry Goncharov
 wrote:
> If we can agree, then i'll file a request to opengroup to explicitly
> state that this
>
> "When an escaped  is found in a command line in a makefile,
> the command line shall contain the , the , and the
> next line, except that the first character of the next line shall not
> be included if it is a ".
>
> takes place after variable expansion.

https://www.austingroupbugs.net/view.php?id=1549

regards, Dmitry

[bug #61805] .ONESHELL causes quoting in .SHELLFLAGS to not work as expected.

[Dmitry Goncharov]

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

Here is a better version of the fix and more tests in sv61805_fix2.diff and
sv61805_test2.diff.

(file #52664, file #52665)
___

Additional Item Attachment:

File name: sv61805_test2.diff Size:1 KB


File name: sv61805_fix2.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #61226] Missing included files that have rules don't show as an error

[Dmitry Goncharov]

Follow-up Comment #10, bug #61226 (project make):

[comment #9 comment #9:]
> I will leave this issue open to think about how to best introduce a
backward-incompatible change that might help in this situation.

Do i understand it correctly, that as long as compatibility allows, you'd like
make to fail whenever make cannot include a makefile, as long as the included
makefile has a rule with a recipe, even empty?

i'd like to mention that en empty recipe in a force rule has the benefit of
avoiding a redundant implicit search. This helps performance and makes a
meaningful debug output, because it removes repetitive "Looking for an
implicit rule..." and "No implicit rules found..." for each .d file.
So, i prefer rules like


%.d:;
%.h:;



___

Reply to this item at:

  

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

[bug #61864] incorrect debug output

[Dmitry Goncharov]

URL:
  

 Summary: incorrect debug output
 Project: make
Submitted by: dgoncharov
Submitted on: Thu 20 Jan 2022 02:30:58 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: None
   Fixed Release: None
   Triage Status: None

___

Details:

Make incorrectly calls an explicitly mentioned file intermediate in
--debug=implicit output.

In this example 'hello.x' is explicitly mentioned and is not intermediate.
Make correctly detects this and treats this file as explicit. Just debug
output is incorrect.


all: hello.tsk
%.tsk: %.x; $(info $@)
unrelated: hello.x


The relevant piece of debug output is


Looking for a rule with intermediate file 'hello.x'.





___

Reply to this item at:

  

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

[bug #61864] incorrect debug output

[Dmitry Goncharov]

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

File name: sv61864_fix.diff   Size:0 KB




___

Reply to this item at:

  

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