[bug #66018] Recommendation: document .ONESHELL behavior in sections concerning line prefixes [@+-]

[anonymous]

URL:
  

 Summary: Recommendation: document .ONESHELL behavior in
sections concerning line prefixes [@+-]
   Group: make
   Submitter: None
   Submitted: Wed 24 Jul 2024 05:33:17 PM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Wed 24 Jul 2024 05:33:17 PM UTC By: Anonymous
Context: I recently was updating a Makefile, and noticed unexpected behavior
when using "@" to prevent Make line echoing. Since the behavior involved
echoing, I searched those docs first. It was only after incrementally removing
other lines that I finally determined that .ONESHELL was responsible for the
behavior I observed, and was able to find the correct documentation. This took
some time.

My recommendation would be to provide a mention of .ONESHELL behavior with
regard to line prefixes in the relevant sections, so that users investigating
issues with their Makefiles can trace more easily from the symptom they
observe to the cause of the behavior.

Such an addition could be very brief. For example:
"'@' has slightly different behavior when the special target '.ONESHELL' is
defined. See the section on '.ONESHELL'."

My recommendation would be to add such a mention in each of the following
sections:
- Section 5.2 (@)
- Section 5.5 (-)
- Section 5.7.1 (+)

My system details:
- GNU Make version 4.4.1
- OpenSUSE Tumbleweed and MacOS via Homebrew







___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[Paul D. Smith]

Follow-up Comment #6, bug #66011 (group make):

Yes; if you structure your makefile pattern rules as Dmitry suggests (which is
definitely the right way to do it: you really don't want to add "extra"
prerequisites to a pattern rule beyond only the exact prerequisite that its
built from, such as the .c file, since any missing prereqs cause the rule to
not match) and put the "extra" prerequisites in a separate rule, then as I
said it will still fail, but you'll get a more understandable error message.

However, best is to have your makefile be resilient to these kinds of things
automatically so you don't have to worry about any of it.

Consider this method for example:
https://make.mad-scientist.net/papers/advanced-auto-dependency-generation/


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[anonymous]

Follow-up Comment #5, bug #66011 (group make):

In my case the nonexisting.h doesn't exist, because I did a refactorization
that removed it, but I forgot to update the header list in the Makefile. After
a while I noticed that making changes to certain headers was not a reason for
recompile, and found out that it's those headers that are listed after
nonexisting.h.

You're right. If a prerequisite file doesn't exist, and there is no rule to
create it, that should be an error.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[Paul D. Smith]

Update of bug #66011 (group make):

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

___

Follow-up Comment #4:

Indeed the prerequisite did attach to the pattern rule, just as the
documentation said that it did.  If it hadn't attached to the pattern rule,
then your pattern rule would have matched.

You are mistaken about what you see when you use "make -d".  The issue is not
that the items after nonexisting.h are ignored.  The issue is that once make
sees nonexisting.h, the pattern rule doesn't match and make goes looking for a
_different_ pattern rule.  Here is some sample output:

 File 'foo.o' does not exist.
 Looking for an implicit rule for 'foo.o'.
  Trying pattern rule '%.o: %.c a.h nonexisting.h c.h Makefile' with stem
'foo'.
  Trying implicit prerequisite 'foo.c'.
  Found 'foo.c'.
  Trying rule prerequisite 'a.h'.
  Found 'a.h'.
  Trying rule prerequisite 'nonexisting.h'.
  Not found 'nonexisting.h'.
  Trying pattern rule '%.o: %.c' with stem 'foo'.
  Trying implicit prerequisite 'foo.c'.
  Found 'foo.c'.
 Found implicit rule '%.o: %.c' for 'foo.o'.

Note carefully that after "Not found 'nonexisting.h'", GNU Make looks at a
completely different rule: the built-in rule to build object files from source
files.  You can run *make -r* to disable the built-in rules, then maybe the
output will be more clear.

Some people think of pattern rules like a C preprocessor macro, where you
expand it and you get a static rule.

But this concept is wrong: a pattern rule is much more like a C++ overloaded
method, where IF all the types match up with the caller then the method is
used, else the compiler will continue looking for some other method to be
used.  If there is no method where the types match up with the caller, then
you have a compiler error.

That's exactly what happens here: make looks for a pattern rule where BOTH (a)
the target matches the pattern, AND (b) _all_ the prerequisites listed in the
rule either exist, or make can discover a way to build them.

If either one of (a) or (b) is not satisfied then the pattern rule does not
match and make continues looking for another pattern rule that will match.  If
make cannot find any pattern rule that matches, then make gives an error
saying it doesn't know how to build the target.

There can be, and often are, many pattern rules for how to build a given
target.  For example you can build an object file from a C source file, C++,
Fortran, assembly, etc.  So make can't just complain about every non-matching
rule.  And by the time make discovers that no rules have matched, it has
forgotten about all the rules that it tried.

Of course it could be possible, with a lot of effort, to remember all the
rules that were tried so that, if everything fails, they could be printed as
part of the error messages, but that effort has not been made and it's not
clear it's worth the effort.

The output of the --debug option should be sufficient to show what happens,
although it does require concentration and/or familiarity to parse it.

Dmitry recommends this formulation:

hello.o: $(HEADERS) Makefile
%.o : %.c
$(CC) $(CFLAGS) -c $<

not because this will work: it will still fail.  He recommends it because in
this situation the error message that make prints will be more understandable.
 This happens because the pattern rule does match (as all the prerequisites
_of the pattern rule_ exist or can be built), but when make goes to try to
build a specific prerequisite of the target nonexisting.h and can't, it will
print a message about that prerequisite not being built, not that there's no
rule to build the object file.

I'm going to close this issue as "Not a Bug" but you can feel free to continue
to discuss things here if the behavior is not clear.  You can also use the
mailing lists such as help-m...@gnu.org if you prefer (that list has a wider
audience).


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[Dmitry Goncharov]

Follow-up Comment #3, bug #66011 (group make):

If you need such a prerequisite and the prerequisite is missing, then the
makefile needs to have a rule to build such a prerequisite.
Depending on your situation this rule can be either a proper rule or dummy
rule like


nonexisting.h:;


In the end, your object files depends on nonexisting.h and nonexisting.h does
not exist and there is no rule to build nonexisting.h.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[anonymous]

Follow-up Comment #2, bug #66011 (group make):

If all the files listed in the prerequisites do exist, the pattern rule that I
wrote works fine. To quote the GNU Make Manual section 10.5.1:

> There may also be prerequisites that do not use ‘%’; such a prerequisite
attaches to every file made by this pattern rule. These unvarying
prerequisites are useful occasionally.

This is one occasion where it is useful.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[Dmitry Goncharov]

Follow-up Comment #1, bug #66011 (group make):

This rule

%.o : %.c $(HEADERS) Makefile

does not apply because nonexisting.h does not exist.

To make there is simply no rule in this makefile to build *.o files.

You want to do something like this instead

hello.o: $(HEADERS) Makefile
%.o : %.c
$(CC) $(CFLAGS) -c $<


i'll need to think if diagnostics can be improved to help the user in this
case.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?66011>

 Summary: dependencies after a non-existing file are silently
ignored
   Group: make
   Submitter: None
   Submitted: Sun 21 Jul 2024 09:56:54 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 21 Jul 2024 09:56:54 AM UTC By: Anonymous
This is how my Makefile looks like:


HEADERS = a.h b.h nonexisting.h c.h d.h

%.o : %.c $(HEADERS) Makefile
$(CC) $(CFLAGS) -c $<


If I change c.h, d.h or the Makefile, make just says "Nothing to be done". If
I run `make -d` I can see that the items beginning with nonexisting.h are not
in the dependency list of the targets. A warning would be nice.

This is make 4.3-4.1 in Debian Unstable.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66011>

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


signature.asc
Description: PGP signature

[bug #65999] make --debug=makefile could be more descriptive

[David Boyce]

URL:
  

 Summary: make --debug=makefile could be more descriptive
   Group: make
   Submitter: boyski
   Submitted: Wed 17 Jul 2024 02:59:13 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Wed 17 Jul 2024 02:59:13 PM UTC By: David Boyce 
In the make command below the indented line says "File 'all' does not exist",
but in this case it's not making a file because "all" has been declared as a
phony target which is not necessarily expected to exist in the form of a file.
The difference between making a file and a phony target may be important in
debugging so I suggest that a message like "Phony target 'all' needs updating"
or similar for phony targets would be more instructive.

$ echo -e ".PHONY: all\nall:" | make-git -f- --debug=makefile
GNU Make 4.4.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
Updating goal targets
 File 'all' does not exist.
Must remake target 'all'.
Successfully remade target file 'all'.
make-git: Nothing to be done for 'all'.







___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65982] make --trace does not explain remade include files

[anonymous]

Follow-up Comment #3, bug #65982 (group make):

Oh, sorry, I didn't R enough of TFM but at least a little doc bug will be
fixed as a result. Sorry for the waste of time otherwise.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65982>

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


signature.asc
Description: PGP signature

[bug #65982] make --trace does not explain remade include files

[Paul D. Smith]

Update of bug #65982 (group make):

  Item Group: Bug => Documentation  

___

Follow-up Comment #2:

This is intended behavior.  The docs for the trace option:
https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002dtrace

say:
> Show tracing information for make execution.
> Using --trace is shorthand for --debug=print,why.

Looking at the --debug option:
https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002ddebug

You'll see this info:
> m (makefile)
> By default, the above messages are not enabled while trying to remake the
makefiles.
> This option enables messages while rebuilding makefiles, too.
> Note that the ‘all’ option does enable this option.
> This option also enables ‘basic’ messages.

However I see that this documentation is incorrect by using the term "above
messages".  What it really means is "other types of output"; e.g., without
this option none of the debug options are enabled while rebuilding makefiles.

So, if you want to get tracing for makefile rebuilds you need to add that
debug option as well.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65982>

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


signature.asc
Description: PGP signature

[bug #65982] make --trace does not explain remade include files

[anonymous]

Follow-up Comment #1, bug #65982 (group make):


> ... also includes 2 generated makefiles ...

Actually the attached version has only one generated makefile (x1.mk) but the
situation is unaffected. 


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65982>

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


signature.asc
Description: PGP signature

[bug #65982] make --trace does not explain remade include files

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?65982>

 Summary: make --trace does not explain remade include files
   Group: make
   Submitter: None
   Submitted: Sat 13 Jul 2024 02:38:49 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 13 Jul 2024 02:38:49 AM UTC By: Anonymous
Consider the following makefile (also attached). It makes one object file
xxx.o and also includes 2 generated makefiles. I want to use --trace to
understand why and when the include files were generated and when make
restarts, in a much larger makefile system of course. But the --trace logic
says nothing about makefile remaking. It explains why the .o is rebuilt but is
silent about the .mk.

Both %.o and %.mk are given artificial dependencies on Makefile. Thus when I
"touch Makefile" all must be rebuilt, but only %.o is and "all" are
explained.

$ cat Makefile
.PHONY: all
all: xxx.o
@:

ifeq ($(filter clean,$(MAKECMDGOALS)),)
  $(info MAKE_RESTARTS=$(MAKE_RESTARTS))
  now := $(shell date)
  include x1.mk
endif

%.mk: Makefile
@:$(info Making $@)
@echo '$$(info Including $$(lastword $$(MAKEFILE_LIST)) at $(now))' >
$@

%.o: %.c Makefile
$(CC) -c -o $@ $<

.PHONY: clean
clean:
$(RM) x1.mk xxx.o

The sequence below shows --trace explaining the rebuild of xxx.o and "all" but
not of x1.mk:

$ make-4.4.1 clean
rm -f x1.mk xxx.o

$ make-4.4.1 --trace
MAKE_RESTARTS=
Making x1.mk
MAKE_RESTARTS=1
Including x1.mk at Fri Jul 12 19:31:26 PDT 2024
Makefile:16: update target 'xxx.o' due to: target does not exist
cc -c -o xxx.o xxx.c
Makefile:3: update target 'all' due to: target is .PHONY
:

$ touch Makefile

$ make-4.4.1 --trace
MAKE_RESTARTS=
Including x1.mk at Fri Jul 12 19:31:26 PDT 2024
Making x1.mk
MAKE_RESTARTS=1
Including x1.mk at Fri Jul 12 19:31:33 PDT 2024
Makefile:16: update target 'xxx.o' due to: Makefile
cc -c -o xxx.o xxx.c
Makefile:3: update target 'all' due to: target is .PHONY
:







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65982>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Paul D. Smith]

Update of bug #65972 (group make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 
Operating System: POSIX-Based => Any

___

Follow-up Comment #7:

I think only admins can close issues, in Savannah.  Thanks for the followup
info!


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Martin Wilck]

Follow-up Comment #6, bug #65972 (group make):

I'm fine with closing this bug, but I don't know how to do it.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Martin Wilck]

Follow-up Comment #5, bug #65972 (group make):

This seems to do the trick:

.SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS))
$(HELPERS:%=%.wrap)

So your suggestion covered it by ~80%. Thanks!


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Paul D. Smith]

Follow-up Comment #4, bug #65972 (group make):

I don't think we will allow "going back" to the old behavior.  That behavior
was just a bug (IMO) and also, your makefile is fragile by relying on it (if
that object file was ever mentioned anywhere else outside of a pattern rule,
it would break).

If my suggestion doesn't work there must be something more subtle going on
that I didn't catch just by reading that specific makefile (I didn't pull the
Git repo or try the build myself).  Hopefully the comment below gives some
tips for how to parse the debug output and things to look for.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Martin Wilck]

Follow-up Comment #3, bug #65972 (group make):

Thanks for your response. I only saw it after adding my last comment.

> .SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS))

That doesn't do the trick, but it seems to go into the right direction. I'll
keep experimenting.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Martin Wilck]

Follow-up Comment #2, bug #65972 (group make):

I bisected this manually to 510e5ce ("[SV 60188] Explicit prereqs cannot be
intermediate files").

So apparently this change was made deliberately in the context of bug #60188.
I wish it was possible to restore the historical behavior.

I wonder if I can do anything about this. Here's my rule, again (simplified
excerpt from the Makefile):


TESTS := uevent dmevents

# these will be evaluated in the implicit rule in
# .SECONDEXPANSION below
dmevents-test_OBJDEPS = $(multipathdir)/devmapper.o
dmevents-test_LIBDEPS = -lpthread -ldevmapper -lurcu

all:$(TESTS:%=%.out)

%.out:  %-test
@echo == running $< ==
@LD_LIBRARY_PATH=.:$(mpathutildir):$(mpathcmddir) ./$< >$@ 2>&1 || { cat
"$@"; false; }

COLON:=:
.SECONDEXPANSION:

%-test: %.o $$($$@_OBJDEPS) $$($$@_TESTDEPS)
@echo building $@
$(Q)$(CC) $(CFLAGS) -o $@ $(LDFLAGS) $< $($@_TESTDEPS) $($@_OBJDEPS)
$(LIBDEPS) $($@_LIBDEPS)


In the case at hand, uevent-test and dmevents-test exist and are newer than
any source files, but no intermediate files exist.

The problem here is $(dmevents-test_OBJDEPS), which expands to an explicit
dependency  on $(multipathdir)/devmapper.o in the %-test rule. This file is
not part of my binary archive, which contains only executables and shared
libraries. 

make 4.3 didn't care that this file didn't exist and regarded dmevents-test
up-to-date nonetheless. 

make 4.4 tries to rebuild $(multipathdir)/devmapper.o, and fails in the
restricted environment. $(uevent-test-OBJDEPS) evaluates to the empty string,
and thus make 4.4 doesn't try to rebuild the uevent-test binary.

The behavior of make 4.3 made more sense to me. dmevents-test depends on two
object files dmevents.o and $(multipathdir)/devmapper.o. It's hard to grok why
the first one can be missing but the other one cannot.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Paul D. Smith]

Follow-up Comment #1, bug #65972 (group make):

Unfortunately the output shown in the comment here is not the important part. 
The important part is why make decided that the -test file needs to be
updated, so you need to look at how make processes the target that is being
rebuilt, not the thing that depends on that target.  And, by extracting only
the "Must build" lines you've lost the information about why make decides it
must be rebuilt.

However, the log files attached do provide this information.

Let us consider for example the dmevents-test target, which 4.3 does not
rebuild but 4.4.1 does.

In the 4.3 version we see these results for this target:

 Finished prerequisites of target file 'dmevents-test'.
 Prerequisite 'dmevents.o' of target 'dmevents-test' does not exist.
 Prerequisite 'dmevents.o.wrap' of target 'dmevents-test' does not exist.
 Prerequisite '../libmultipath/devmapper.o' of target 'dmevents-test' does
not exist.
 Prerequisite 'libmultipath.so.0' is older than target 'dmevents-test'.
 Prerequisite '../libmpathutil/libmpathutil.so.0' is older than target
'dmevents-test'.
 Prerequisite '../libmpathcmd/libmpathcmd.so.0' is older than target
'dmevents-test'.
 Prerequisite 'Makefile' is older than target 'dmevents-test'.
No need to remake target 'dmevents-test'.

while in 4.4.1 we see these results:

  Finished prerequisites of target file 'dmevents-test'.
   Prerequisite 'dmevents.o' is newer than target 'dmevents-test'.
   Prerequisite 'dmevents.o.wrap' is newer than target 'dmevents-test'.
   Prerequisite '../libmultipath/devmapper.o' is newer than target
'dmevents-test'.
   Prerequisite 'libmultipath.so.0' is older than target 'dmevents-test'.
   Prerequisite '../libmpathutil/libmpathutil.so.0' is older than target
'dmevents-test'.
   Prerequisite '../libmpathcmd/libmpathcmd.so.0' is older than target
'dmevents-test'.
   Prerequisite 'Makefile' is older than target 'dmevents-test'.
  Must remake target 'dmevents-test'.


Examining the 4.4.1 logs, it appears to me that the important difference is
actually this line:

   Prerequisite '../libmultipath/devmapper.o' is newer than target
'dmevents-test'.

Once this prerequisite is decided to be rebuilt, then all the other
prerequisites, which were considered intermediate due to the .SECONDARY
statement, also must be rebuilt.

So why is this target rebuilt?  Well, it's not marked as intermediate because
it doesn't appear in the OBJS variable, and make knows that we can build a
../libmultipath/devmapper.o from a ../libmulitpath/devmapper.c which does
exist, so this behavior makes sense to me.

In other words, to me it looks like GNU Make 4.3 is wrong and GNU Make 4.4.1
is correct.

Maybe it would help to declare all the object files .SECONDARY, not just the
TEST objects and helpers; e.g., change:

.SECONDARY: $(OBJS)

to something like this:

.SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS))

Does that allow it to work the way you want?


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Martin Wilck]

Additional Item Attachment, bug #65972 (group make):

File name: sid.logSize: 356KiB
<https://file.savannah.gnu.org/file/sid.log?file_id=56249>

File name: f40.logSize: 597KiB
<https://file.savannah.gnu.org/file/f40.log?file_id=56250>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-05e690add83a426b3815318aa602289c02cdb981.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65972>

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Martin Wilck]

URL:
  <https://savannah.gnu.org/bugs/?65972>

 Summary: Change in dependency treatment between GNU make 4.3
and 4.4.1
   Group: make
   Submitter: mwilck
   Submitted: Wed 10 Jul 2024 02:59:38 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Wed 10 Jul 2024 02:59:38 PM UTC By: Martin Wilck 
I noted a change between make 4.3 and 4.4.1. In short, make 4.4.1 tries to
rebuild certain targets which were considered up to date in 4.3.

In the CI for [https://github.com/openSUSE/multipath-tools/ multipath-tools],
I sometimes need to package the binary artifacts for the CI (all libraries and
the CI programs linking to them) in an archive, in order to unpack and run
them in a different environment. This is useful for building CI for non-native
architectures, for example (cross-compiling on x86_64, archiving the results,
and then running the cross-compiled test programs under qemu is much faster
then doing the entire compilation and testing under qemu).

The command I use for running the tests is "make -C tests". The Makefile has
rules to run the test programs, roughly like this (the real logic is more
complex):


all:$(TESTS:%=%.out)

%.out:  %-test
./$< >$@


After unpacking the archive with the test programs and libraries, 
these rules would simply run all xxx-test programs and store the results in
the respective xxx.out files. At least this is how it worked until make 4.3.

With GNU make 4.4.1, make tries to rebuild some of the test programs, which
fails, because the environment for running the tests is lacking some of the
tools and libraries required for building.

Here is a reproducer. So far I couldn't come up with anything simpler, sorry.


> git clone -b tip --single-branch
https://github.com/openSUSE/multipath-tools
> cd multipath-tools

# Use a preconfigured container with all dependencies for building
multipath-tools
# Note that these containers have "make" as entrypoint
> podman run -it --rm  -v $PWD:/build
ghcr.io/mwilck/multipath-build-debian-sid -j8 test-progs.tar

# clean up
> mv test-progs.tar  /tmp/
> git clean -d -f -x

# Unpack the test programs. Note the "m" flag to make sure the time stamps of
the programs are newer than those of the sources / dependencies.
tar xfm /tmp/test-progs.tar

# Under Debian Sid (make 4.4.3), this just runs the test programs
# Note that these containers have "make" as entrypoint
> podman run -it --rm  -v $PWD:/build
ghcr.io/mwilck/multipath-build-debian-sid -C tests --dry-run
make: Entering directory '/build/tests'
echo == running uevent-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./uevent-test >uevent.out
2>&1 || { cat "uevent.out"; false; }
echo == running parser-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./parser-test >parser.out
2>&1 || { cat "parser.out"; false; }
echo == running util-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./util-test >util.out 2>&1 ||
{ cat "util.out"; false; }
echo == running dmevents-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./dmevents-test >dmevents.out
2>&1 || { cat "dmevents.out"; false; }
echo == running hwtable-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./hwtable-test >hwtable.out
2>&1 || { cat "hwtable.out"; false; }
echo == running blacklist-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./blacklist-test
>blacklist.out 2>&1 || { cat "blacklist.out"; false; }
echo == running unaligned-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./unaligned-test
>unaligned.out 2>&1 || { cat "unaligned.out"; false; }
...

# But under Fedora (make 4.4.1), it tries to rebuild some of the binaries:
# Note that these containers have "make" as entrypoint
> podman run -it --rm  -v $PWD:/build ghcr.io/mwilck/multipath-build-fedora-40
-C tests --dry-run
make: Entering directory '/build/tests'
echo == running uevent-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./uevent-test >uevent.out
2>&1 || { cat "uevent.out"; false; }
echo == running parser-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./parser-test >parser.out
2>&1 || { cat "parser.out"; false; }
echo == running util-test ==
LD_LIBRARY_PATH=.:../libmpathutil:../libmpathcmd ./util-test >util.out 2>&1 |

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

[Hannes Domani]

Follow-up Comment #1, bug #65917 (group make):

I've come up with this patch:

diff --git a/src/remake.c b/src/remake.c
index ee8971e7..9d33351f 100644
--- a/src/remake.c
+++ b/src/remake.c
@@ -1090,11 +1090,16 @@ notice_finished_file (struct file *file)
   d->file->update_status = file->update_status;
 
   if (ran && !d->file->phony)
-/* Fetch the new modification time.
-   We do this instead of just invalidating the cached time
-   so that a vpath_search can happen.  Otherwise, it would
-   never be done because the target is already updated.  */
-f_mtime (d->file, 0);
+{
+  if (just_print_flag)
+d->file->last_mtime = NEW_MTIME;
+  else
+/* Fetch the new modification time.
+   We do this instead of just invalidating the cached time
+   so that a vpath_search can happen.  Otherwise, it would
+   never be done because the target is already updated.  */
+f_mtime (d->file, 0);
+}
 }
 
   /* If the target was created by an implicit rule, and it was updated,

Not sure how correct it is, but so far it's working for me.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65917>

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

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

[Hannes Domani]

URL:
  <https://savannah.gnu.org/bugs/?65917>

 Summary: --dry-run doesn't handle pattern rules with multiple
targets correctly
   Group: make
   Submitter: ssbssa
   Submitted: Mon 24 Jun 2024 06:23:53 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Mon 24 Jun 2024 06:23:53 PM UTC By: Hannes Domani 
Using this file:

all:

alpha.p beta.p:
touch $@

%.c %.h: %.p
touch $*.c $*.h

alpha.o: alpha.c alpha.h beta.h
touch $@

beta.o: beta.c beta.h alpha.h
touch $@

executable: alpha.o beta.o
touch $@

all: executable


First create all targets:

$ make
touch alpha.p
touch alpha.c alpha.h
touch beta.p
touch beta.c beta.h
touch alpha.o
touch beta.o
touch executable


Remaking all targets depending on beta.p:

$ touch beta.p
$ make --dry-run
touch beta.c beta.h
touch alpha.o
touch beta.o
touch executable
$ make
touch beta.c beta.h
touch alpha.o
touch beta.o
touch executable

Both with and without --dry-run has the same result.
But trying to do the same with alpha.p:

$ make --dry-run
touch alpha.c alpha.h
touch alpha.o
touch executable
$ make
touch alpha.c alpha.h
touch alpha.o
touch beta.o
touch executable

You see that --dry-run is missing 'touch beta.o'.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65917>

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

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[KO Myung-Hun]

Follow-up Comment #3, bug #65908 (group make):

Then, it would be better that make provides the infos about that line not
mis-matched `endif'.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65908>

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

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Henrik Carlqvist]

On Sat, 22 Jun 2024 15:49:26 +
Martin Dorey  wrote:
> Um, Henrik... 4.4.90 is the latest in git:

Yes, I now see that you are right and that has been the "version number" of
all commits in git since version 4.4.1.

> ...the de facto OS/2 maintainer...

Whoops, my bad... I did remember when support for OS/2 was dropped, but I did
not remember that eventually someone picked it up again.

regards Henrik

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Paul D. Smith]

Follow-up Comment #2, bug #65908 (group make):

You should review this Git patch:

https://public-inbox.org/git/9d14c08ca6cc06cdf8fb4ba33d2470053dca3966.1712591504.git...@ttaylorr.com/

See this section of the GNU Make manual:
> Extra spaces are allowed and ignored at the beginning of the conditional
directive line, but a tab is not allowed.

This has always been true, but in older releases there were some situations in
which it worked to indent with tabs.  In the current Git latest commit this no
longer works.

It's possible we will find a way to preserve the bug fix that we installed
that caused this problem, while still allowing some or most of the previous
support, at least for the time being, before an official release is made.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65908>

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

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Martin Dorey]

Follow-up Comment #1, bug #65908 (group make):

I see line 3857 is the end of Makefile... and that the likely reason the
testcase is so large is because it's hard to work out where the if/endif
matching has gone astray.  For me, running on Linux, the error initially
reported is different:


mad@shuttle:~/tmp/make-65908/extracted-endif-testcase.zip/git$
~/Downloads/make/make --version
GNU Make 4.4.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
mad@shuttle:~/tmp/make-65908/extracted-endif-testcase.zip/git$
~/Downloads/make/make
config.mak.uname:866: *** missing 'endif'.  Stop.
mad@shuttle:~/tmp/make-65908/extracted-endif-testcase.zip/git$ 


Some extra printf debugging revealed that things went astray with the
tab-indented endif at config.mak.uname line 70 not being treated as a Make
control directive, so not closing the tab-indented ifneq two lines earlier. 
It's in the middle of a bunch of assignments, rather than a recipe, so my
initial thought is that Make's gone wrong here.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65908>

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

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Martin Dorey]

Um, Henrik... 4.4.90 is the latest in git:

https://git.savannah.gnu.org/cgit/make.git/tree/configure.ac#n31

… and the OP here, who is probably on-list despite the invalid.noreply 
business, is, or at least shares a rather particular name with, the de facto 
OS/2 maintainer, innit, as credited in the 4.4.1 release announcement:

https://lists.gnu.org/archive/html/info-gnu/2023-02/msg00011.html

... which superseded the 4.4 one:

https://lists.gnu.org/archive/html/info-gnu/2022-10/msg8.html

... which heralded the deprecation of OS/2 support.

I'm off to look at the spaces on the if/endif directives, as with the Linux 
kernel makefiles, will reply further in Savannah...


From: bug-make-bounces+martin.dorey=hds@gnu.org 
 on behalf of Henrik Carlqvist 

Sent: Saturday, June 22, 2024 08:21
To: Henrik Carlqvist 
Cc: invalid.nore...@gnu.org ; psm...@gnu.org 
; bo...@kolpackov.net ; bug-make@gnu.org 

Subject: Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. 
Stop.

* EXTERNAL EMAIL *

On Sat, 22 Jun 2024 16:57:17 +0200
Henrik Carlqvist  wrote:

> > Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938,
> > and I'm working on OS/2.
> >
> > v4.4.1 works fine.
>
> In lack of OS/2 maintainer the official GNU Make dropped support for OS/2
> somewhere around version 4.4. It seems as if some unofficial fork was done
> at 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkomh%2Fmake-os2=05%7C02%7Cmartin.dorey%40hds.com%7Cc1204a5f6e984af585e308dc92cf0ac9%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C638546665157247882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=drYlRwwXte6Hg%2FvLK4XyLB5FM6G9q9ILDtCV%2FSsME%2F4%3D=0<https://github.com/komh/make-os2>
>  but that fork does not seem to have put
> the effort in to follow continued work with GNU Make.

Whoops, I now see that version 4.4.1 is the latest official release. I am not
awer of any 4.4.90 version, there was a 4.4.0.90 version which is older than
4.4.1. Commit e3f938 is the latest commit, but no official release. That
commit was made to the official GNU Make repo which has dropped OS/2 support.

regards Henrik

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Henrik Carlqvist]

On Sat, 22 Jun 2024 16:57:17 +0200
Henrik Carlqvist  wrote:

> > Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938,
> > and I'm working on OS/2.
> > 
> > v4.4.1 works fine.
> 
> In lack of OS/2 maintainer the official GNU Make dropped support for OS/2
> somewhere around version 4.4. It seems as if some unofficial fork was done
> at https://github.com/komh/make-os2 but that fork does not seem to have put
> the effort in to follow continued work with GNU Make.

Whoops, I now see that version 4.4.1 is the latest official release. I am not
awer of any 4.4.90 version, there was a 4.4.0.90 version which is older than
4.4.1. Commit e3f938 is the latest commit, but no official release. That
commit was made to the official GNU Make repo which has dropped OS/2 support.

regards Henrik

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Henrik Carlqvist]

> Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938,
> and I'm working on OS/2.
> 
> v4.4.1 works fine.

In lack of OS/2 maintainer the official GNU Make dropped support for OS/2
somewhere around version 4.4. It seems as if some unofficial fork was done at
https://github.com/komh/make-os2 but that fork does not seem to have put the
effort in to follow continued work with GNU Make.

regards Henrik

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[KO Myung-Hun]

URL:
  <https://savannah.gnu.org/bugs/?65908>

 Summary: Make fails with 'Makefile:3857: *** missing 'endif'.
 Stop.
   Group: make
   Submitter: lvzuufx
   Submitted: Sat 22 Jun 2024 01:44:50 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: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 22 Jun 2024 01:44:50 PM UTC By: KO Myung-Hun 
Hi/2.

While I'm working on git, make failed like :

Makefile:3857: *** missing 'endif'.  Stop.

Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938, and
I'm working on OS/2.

v4.4.1 works fine.

I attach the testcase.






___
File Attachments:


---
Name: endif-testcase.zip  Size: 45KiB
<https://file.savannah.gnu.org/file/endif-testcase.zip?file_id=56183>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-3cd0d2c94962908e0e7c31b0cfb957af29c7d567.tar.gz

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65908>

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

[bug #65863] release failing jobs last when -j and -O in use

[anonymous]

URL:
  

 Summary: release failing jobs last when -j and -O in use
   Group: make
   Submitter: None
   Submitted: Sun 09 Jun 2024 10:28:12 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 09 Jun 2024 10:28:12 PM UTC By: Anonymous
Relaying a suggestion from a co-worker ... when -j and -O are both in use,
parallel jobs will be running with their output impounded until completion.
The suggestion is that when these conditions are met *and* one or more jobs
fails, the output of the failing job(s) should be released after that of the
successful jobs such that error messages land near the end of the build log as
they would be in a failing serial build.

Does this does sound like it might be useful and not too hard to implement?







___

Reply to this item at:

  

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

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

[Dan D]

Follow-up Comment #2, bug #65773 (group make):


[comment #1 comment #1:]
> This patch is fine by me, but I believe we will need a copyright assignment
for you to accept this and other patches you sent.
> 
> Would you like me to send you the form to fill and the instructions to go
with it, so you could start your assignment paperwork rolling?

Sent you an email.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65773>

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

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

[Dan D]

Follow-up Comment #3, bug #65771 (group make):

Revised "restore Visual C 6 and newer but older VC 200X builds"

-more std C types/casts used, no more app specific "_quad_t" type

also added a 2nd patch fixing build/compile time, for gnumake on old or very
old (2000s era) Mingw GCCs for Win32. Putting it in this ticket, because I
think it won't apply unless "restore VC6" patch is applied. Commit history
looks better if its 2 separate commits in a row. 

So patch #2, for old Mingw GCC, this patch also restores RUNTIME execution of
gnumake+any Mingw GCC, modern or old!!! on WinXP. Mingw GCC+gnumake binaries,
would not execute at all, by WinXP OS (Win 7 & up, the gnumake.exe execs
fine). Mingw version made no difference for WinXP refusing to exec the .exe,
because of the XML manifest file from the email/thread/commit below, is parsed
as malformed/unknown schema/XML Tags for WinXP's kernel. So I added the
correct back-compat XML stuff, and WinXP+Gnumake+Mingw runs fine on XP now.

https://lists.gnu.org/archive/html/bug-make/2023-03/msg00101.html

Revision: b2bf660abc4611677670b01fcbb0dc94ce2c35f7
Author: Costas Argyris 
Date: 6/19/2023 9:51:13 AM
Message: Add a UTF-8 resource when building for Windows


(file #56105, file #56106)

___

Additional Item Attachment:

File name: 0001-restore-Visual-C-6-and-newer-but-older-VC-200X-build.patch
Size: 24KiB
   
<https://file.savannah.gnu.org/file/0001-restore-Visual-C-6-and-newer-but-older-VC-200X-build.patch?file_id=56105>

File name: 0002-Win32-fix-build-for-compat-with-mid-2000s-Mingw-GCCs.patch
Size: 9KiB
   
<https://file.savannah.gnu.org/file/0002-Win32-fix-build-for-compat-with-mid-2000s-Mingw-GCCs.patch?file_id=56106>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65771>

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

[bug #65776] [PATCH 1/3] win32 STAT_LITE

[Dan D]

Follow-up Comment #2, bug #65776 (group make):

I check my Win2K PC, kernel32.dll has GetFileAttributesEx, my WinME also has
GetFileAttributesEx, my Win 95 test box, NO.

https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/250301
says GFAEx() added Win 98 for Dos Windows family

https://www.geoffchappell.com/studies/windows/win32/kernel32/history/names40.htm
added in NT 4.0 for NT Kernel family

I'd vote to abandon support for Win 95, since its a DOS Win OS, and the DOS
Windows (95/98/ME) were always unstable, and its very unlikely any
legacy/airgap type, business users, still exist. The legacy business users
would have all picked NT 4 or Win 2K at the time (1998-2003 ish) for
BSOD/stability reasons for whatever private biz apps they were using. Plus
GFAEx() is available on Win 98/ME, so gnumake isn't dropping all "dos win"
support, with this improvement/patch, just Win 95. By still supporting Win98
"on paper", gnumake is compat with 25 years of Dos Win, and NT 4, even more
years.


I could write a runtime function symbol name lookup LoadLibrary/GetProcAddress
and fallback to a stat() shim at runtime if GFAEx() is missing. I might need a
global Win32 stat() shim or total stat() reimplement, that I will put in
another patch ticket, for early 2000s GCC Mingw 3.4.5, I see severe perf
problems, or 32b vs 64b time_t/file_timestamp_t/stat() problems with that CC.
My VC 6 same Win2k machine is fine.

small chance this "stat_lite()" function might become "stat_full()" for VC 6
build in the future, or GCC+Win 2000, or any CC+Win2K, because of the CC's or
the old Win OS's libc's 32 bit time_t and/or 32b file size C struct, and 64b
stat()/time() is unimplement by the CC or OS, 1998-2000-ish, and gmake casting
up/down those 2 pieces of data, to 64b and down to 32b in many places. And
gmake C code base, I'd throw a wild guess, is too dependent on 64b time_t/64b
file size by 2024.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65776>

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

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

[Dan D]

Follow-up Comment #2, bug #65771 (group make):

[comment #1 comment #1:]
> Thanks.  Some comments to the proposed patch:
> 
> @@ -576,8 +578,8 @@ char *ttyname (int);
>  
>  /* Define {u,}intmax_t if not defined in  or . */
>  #if !HAVE_STDINT_H && !HAVE_INTTYPES_H
> -#define intmax_t long long
> -#define uintmax_t unsigned long long
> +#define intmax_t __int64
> +#define uintmax_t unsigned __int64
>  #endif
> 
> IMO, these changes should not be unconditional, but conditioned by _MSC_VER.
 It makes little sense to use __int64 in a GCC build.

Agree.

> --- a/src/dir.c
> +++ b/src/dir.c
> @@ -1106,7 +1106,7 @@ print_dir_data_base (void)
>  #if MK_OS_W32
>  printf (_("# %s (key %s, mtime %s): could not be opened.\n"),
>  dir->name, dir->contents->path_key,
> -make_ulltoa ((unsigned long long)dir->contents->mtime,
buf));
> +make_ulltoa ((unsigned _quad_t)dir->contents->mtime,
buf));
> 
> Sane here.  And I don't understand why you use the _quad_t type here; at the
very least you should use unsigned __int64, no?  Similar comments to other
uses of _quad_t.
> 
> The definition of _quad_t that you suggest in makeint.h is perhaps okay, but
then (a) please don't use lower-case symbold that begins with an underscore,
as that is generally reserved, and (b) why have both intmax_t/uintmax_t and
_quad_t?

file "dir.c" is cross platform, so I was thinking to minimize OS specific
code, especially multi line "#ifdef"s. But there is a better way to rewrite it
on me doing a 2nd look.

Other FOSS projects uses term "QUAD"/"quad" or VENDORPREFIX_64_T etc in a PP
define or typedef, for a portable, MS Win32-okay 64b int type. "int64_t" I
think is too new for gnumake's compat standards, all OSes (correct if wrong).
Gnumake vs Win32 vs maybe other OSes in 2020s already had compat and
portable-problems with "int64_t" when T look in git histoy, which caused "long
long" to get added, etc, etc.  I didnt want to introduce >=C99 fallbacks, for
old CCs, and the fallbacks have unprefixed C99/ANSI tokens/identifiers. I just
invented "_quad_t", I assumed the community would suggest a better label
anyways when I post the patch for public review.

I considered, some mistake, either by gnumake devs, or end user patches, IDK
what, accidentally the C99 fallback code is compiled on a C99 or 2020s CC, or
future CCs, and a gmake 2024 era code snapshot, the gmake build somehow breaks
in 2024 or a 2024 gmake code tarball with a future 2030 CC in 2030. So I
picked "_quad_t" label so no conflict even if a mistake happen and fallback is
built on a C99/modern CC.  I couldn't think of a better label in the patch 1st
revision. 

"#if _MSC_VER < VC 2010 \n #define int64_t __int64" works, but egh, Ive seen
other FOSS projects typically create a VENDOR_64_T, not "typedef signed
__int64 int64_t;"

On a second thinking, there is a better fix. That "long long" cast was added
in

https://git.savannah.gnu.org/cgit/make.git/commit/?id=6f7fb050b4af7335de259f570b75bf6c217eb1cd

and it already is in a "#ifdef WIN32". So for any "retro Win32 computing"
builds, I declare VC6 support is lowest denominator needed. And VC 6 has 64b
ints native. You get Win95/NT 3.51 IDK NT 4 compat with VC6, my personal biz
req for private code is W2K. gmake already, so for 100% of Win32 32b, all CCs
versions, retro and modern already use __int64. Mingw GCC obv must support
__int64 for compat.

current Win32 gmake, has "uintmax_t"->unsigned __int64" hard coded. So that
should be a (uintmax_t) cast, not (unsigned long long), and not (VENDOR_64T).
A zero/sign extend guard, is always good to put in, even if not need. Future
code reasons/future user reasons. Current Win32 gmake doesn't need that cast,
but obv some Win32 CC was printing console warning, probably on 32b sign
extend vs zero extend to 64b hazard. (uintmax_t) cast solves that.

current gmake is

FILE_TIMESTAMP->uintmax_t->Windows unsigned __int64

So a cast is just for CC silence the warning, and a tiny bit future dev
error.

Some accident, some end user changes, gmake C code, for his personal built, at
some future point, and gmake FILE_TIMESTAMP type is signed 32b, and uintmax_t
type is 64b (user mistake), on a 64b OS, atleast do the cast, for zero extend.
I will rework it to (uintmax_t).



> --- a/src/job.c
> +++ b/src/job.c
> @@ -22,6 +22,7 @@ this program.  If not, see
<https://www.gnu.org/licenses/>.  */
>  /* Default shell to use.  */
>  #if MK_OS_W32
>  # include 
> +# include  /* for WSABASEERR */
> 
> I don't understand the need for this.  The following MS documentation page:
> 
>   
https://learn.microsoft.com/en-us/windows/win32/wi

[bug #65777] add const misc global RO arrays

[Eli Zaretskii]

Update of bug #65777 (group make):

Severity:  3 - Normal => 1 - Wish   
 Assigned to:None => psmith 
   Component Version:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

Thanks.

These are basically cleanups.  I'm not sure we should make significant changes
in complicated code just to improve memory efficiency by a tiny bit.  I'll let
Paul make the decision, but my tendency is not to install these patches.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65777>

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

[bug #65776] [PATCH 1/3] win32 STAT_LITE

[Eli Zaretskii]

Follow-up Comment #1, bug #65776 (group make):

We don't use GetFileAttributesEx because it doesn't exist on old Windows
systems, and GNU Make still wants to support those old systems.

So I don't think we should make these changes, sorrty.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65776>

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

[bug #65775] [PATCH 2/2] win32 dir.c eliminate OS specific dir-cache agressive reread vs posix

[Eli Zaretskii]

Update of bug #65775 (group make):

 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

Please elaborate on the need for these changes.  What are the advantages of
installing these two patches wrt the current code?  Is the current code wrong?
 Is it slower than the code after your changes?  Something else?

Again, this code is old and stable, so changing it needs a good reason, IMO.

Thanks.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65775>

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

[bug #65774] [PATCH] win32: use link time optimization for Visual C Release build

[Eli Zaretskii]

Update of bug #65774 (group make):

Severity:  3 - Normal => 2 - Minor  
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

I have no objections to installing this patch, subject to copyright assignment
paperwork.

Thanks.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65774>

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

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

[Eli Zaretskii]

Update of bug #65773 (group make):

Severity:  3 - Normal => 2 - Minor  
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

This patch is fine by me, but I believe we will need a copyright assignment
for you to accept this and other patches you sent.

Would you like me to send you the form to fill and the instructions to go with
it, so you could start your assignment paperwork rolling?



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65773>

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

[bug #65772] [PATCH] win32: don't twice search disk for $(SHELL) unless PATH or SHELL changed

[Eli Zaretskii]

Update of bug #65772 (group make):

Severity:  3 - Normal => 1 - Wish   
  Status:None => Wont Fix   
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Thanks, but no thanks.  This part of GNU Make is very old and it is stable. 
It is also tricky, as the issue of the value of SHELL in GNU Make on
MS-Windows is complicated.  I'm not interested in potentially destabilizing it
for the benefit of a couple of milliseconds.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65772>

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

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

[Eli Zaretskii]

Update of bug #65771 (group make):

Severity:  3 - Normal => 2 - Minor  
  Item Group: Enhancement => Build/Install  
 Assigned to:None => eliz   
   Component Version:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Thanks.  Some comments to the proposed patch:

@@ -576,8 +578,8 @@ char *ttyname (int);
 
 /* Define {u,}intmax_t if not defined in  or . */
 #if !HAVE_STDINT_H && !HAVE_INTTYPES_H
-#define intmax_t long long
-#define uintmax_t unsigned long long
+#define intmax_t __int64
+#define uintmax_t unsigned __int64
 #endif

IMO, these changes should not be unconditional, but conditioned by _MSC_VER. 
It makes little sense to use __int64 in a GCC build.

--- a/src/dir.c
+++ b/src/dir.c
@@ -1106,7 +1106,7 @@ print_dir_data_base (void)
 #if MK_OS_W32
 printf (_("# %s (key %s, mtime %s): could not be opened.\n"),
 dir->name, dir->contents->path_key,
-make_ulltoa ((unsigned long long)dir->contents->mtime,
buf));
+make_ulltoa ((unsigned _quad_t)dir->contents->mtime,
buf));

Sane here.  And I don't understand why you use the _quad_t type here; at the
very least you should use unsigned __int64, no?  Similar comments to other
uses of _quad_t.

The definition of _quad_t that you suggest in makeint.h is perhaps okay, but
then (a) please don't use lower-case symbold that begins with an underscore,
as that is generally reserved, and (b) why have both intmax_t/uintmax_t and
_quad_t?

--- a/src/job.c
+++ b/src/job.c
@@ -22,6 +22,7 @@ this program.  If not, see <https://www.gnu.org/licenses/>. 
*/
 /* Default shell to use.  */
 #if MK_OS_W32
 # include 
+# include  /* for WSABASEERR */

I don't understand the need for this.  The following MS documentation page:

  
https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2

says that these errors are also declared in winerror.h, which windows.h
includes.  So why did you need an explicit inclusion on winsock2.h?

+#if (defined(_MSC_VER) && (_MSC_VER < 1900))
+//must use shim on all < VC 2015 s
+//
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
+#define snprintf _snprintf_c99

First, please don't use C++-style "//" comments.
And second, why was this needed? (I've read the page which you quote, and I
still don't think I understand the need, please explain.)

-# include /* for intptr_t */
+# include /* for INT_PTR */

Is INT_PTR indeed defined in stddef.h?  I very much doubt that.

 osync_parse_mutex (const char *mutex)
 {
   char *endp;
-  unsigned long long i;
+  UINT_PTR i;
 
   errno = 0;
+#if defined _WIN64
   i = strtoull (mutex, , 16);
+#else
+  i = strtoul (mutex, , 16);
+#endif

Why this change?  It adds an ugly #ifdef for no good reason.  Why not handle
the mutex as unsigned long long (a 64-bit type) in both 32-bit and 64-bit
builds?

+/*VC 6 doesn't have strtoi64, VC 7/2003 does */
+#if defined(_MSC_VER) && (_MSC_VER < 1300)
+/*  from ReactOS /sdk/lib/crt/string/strtoi64.c
+https://git.reactos.org/?p=reactos.git;a=blob;f=COPYING3;hb=HEAD
+*/
+/* Based on Wine Staging 1.9.9 - dlls/msvcrt/string.c */

If this code is indeed from Wine, I'm not sure we can accept it without them
assigning the copyright to us.  That's Paul's decision, obviously, but AFAIK
those are the rules of the GNU project regarding non-trivial contributions of
code.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65771>

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

[bug #65777] add const misc global RO arrays

[Dan D]

Follow-up Comment #2, bug #65777 (group make):

putting up rev 3, save/commit mistakes by me

(file #56090)

___

Additional Item Attachment:

File name: 0001-job.c-read.c-add-const-to-global-arrays-of-strings-r.patch
Size: 9KiB
   
<https://file.savannah.gnu.org/file/0001-job.c-read.c-add-const-to-global-arrays-of-strings-r.patch?file_id=56090>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65777>

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

[bug #65777] add const misc global RO arrays

[Dan D]

Follow-up Comment #1, bug #65777 (group make):

1st patch "job.c read.c: add const to global arrays of strings" didn't
compile, attached new version of "job.c read.c: add const to global arrays of
strings"

(file #56089)

___

Additional Item Attachment:

File name: 0001-job.c-read.c-add-const-to-global-arrays-of-strings.patch Size:
11KiB
   
<https://file.savannah.gnu.org/file/0001-job.c-read.c-add-const-to-global-arrays-of-strings.patch?file_id=56089>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65777>

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

[bug #65759] handling of "-" and "--" on command line

[Paul D. Smith]

Follow-up Comment #5, bug #65759 (group make):

I looked through the code.  This is explicitly handled, and ignored, with a
commit message by Roland from 1995 saying only:

commit 636435e5c25d39fc5d52edf936e8e7a410b31b1a
Author: Roland McGrath 
Date:   1995-03-07 22:31:01 +

(decode_switches): If non-option arg is "-", ignore it.

So, I'm not sure why this was done or what the right thing to do is going
forward.  Maybe we should be printing a warning.  I wonder if it's there
because some makefiles contain recipes like this:

  submake:
  $(MAKE) -$(MAKEFLAGS)

where, if MAKEFLAGS is empty you get *make -*.

I will think about it.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65759>

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

[bug #65777] add const misc global RO arrays

[Dan D]

URL:
  

 Summary: add const misc global RO arrays
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:24:17 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  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


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:24:17 AM UTC By: Dan D 
see 2 patches, the array of "array of pointers to strings" can be const/stored
in RO mem






___
File Attachments:


---
Name: 0001-add-const-misc-global-RO-arrays-part-1.patch  Size: 6KiB

---
Name: 0002-job.c-read.c-add-const-to-global-arrays-of-strings.patch  Size:
10KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65776] [PATCH 1/3] win32 STAT_LITE

[Dan D]

URL:
  

 Summary: [PATCH 1/3] win32 STAT_LITE
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:21:38 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:21:38 AM UTC By: Dan D 
3 parts for clear git history/dev logic, can be squashed if needed






___
File Attachments:


---
Name: 0001-win32-STAT_LITE-part-1.patch  Size: 5KiB

---
Name: 0002-win32-STAT_LITE-part-2.patch  Size: 7KiB

---
Name: 0003-win32-STAT_LITE-part-3.patch  Size: 4KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65775] [PATCH 2/2] win32 dir.c eliminate OS specific dir-cache agressive reread vs posix

[Dan D]

URL:
  

 Summary: [PATCH 2/2] win32 dir.c eliminate OS specific
dir-cache agressive  reread vs posix
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:15:27 AM 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: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:15:27 AM UTC By: Dan D 
patch 1 and 2 are together in this ticket, i probably shudve squashed them but
i didnt for git history reasons (if thats a reason)






___
File Attachments:


---
Name: 0001-win32-dir.c-prove-dir-cache-win32-only-mtime-field-u.patch  Size:
4KiB

---
Name: 0002-win32-dir.c-eliminate-OS-specific-dir-cache-agressiv.patch  Size:
2KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65774] [PATCH] win32: use link time optimization for Visual C Release build

[Dan D]

URL:
  

 Summary: [PATCH] win32: use link time optimization for Visual
C Release build
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:13:06 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:13:06 AM UTC By: Dan D 
see patch






___
File Attachments:


---
Name: 0001-win32-use-link-time-optimization-for-Visual-C-Releas.patch  Size:
2KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

[Dan D]

URL:
  

 Summary: [PATCH] win32: on VC always make PDB debugging
symbols for Release
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:12:06 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:12:06 AM UTC By: Dan D 
see patch






___
File Attachments:


---
Name: 0001-win32-on-VC-always-make-PDB-debugging-symbols-for-Re.patch  Size:
2KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65772] [PATCH] win32: don't twice search disk for $(SHELL) unless PATH or SHELL changed

[Dan D]

URL:
  

 Summary: [PATCH] win32: don't twice search disk for $(SHELL)
unless PATH or  SHELL changed
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:11:09 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:11:09 AM UTC By: Dan D 
see patch






___
File Attachments:


---
Name: 0001-win32-don-t-twice-search-disk-for-SHELL-unless-PATH-.patch  Size:
6KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

[Dan D]

URL:
  

 Summary: [PATCH] restore Visual C 6 and newer but older VC
200X builds
   Group: make
   Submitter: bulk88
   Submitted: Thu 23 May 2024 12:09:44 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 23 May 2024 12:09:44 AM UTC By: Dan D 
see patch






___
File Attachments:


---
Name: 0001-restore-Visual-C-6-and-newer-but-older-VC-200X-build.patch  Size:
22KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4b48cbb9570c156bf7d681225b664258d7028914.tar.gz

___

Reply to this item at:

  

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

[bug #65759] handling of "-" and "--" on command line

[anonymous]

Follow-up Comment #4, bug #65759 (group make):

(original poster) Understood about --. WRT -, I don't think it should be an
error, I think it should be treated as a filename as Dmitry says.

IMHO the interesting question is: given that - should be treated as a valid
filename, should it be required to come after a --? I haven't read the POSIX
standard closely so I don't know what it might require but intuitively it
seems that - without -- could be treated as a bogus option whereas after -- it
must be a valid filename. This does not seem to be happening now:

$ cat Makefile
%:; @:$(info creating $@)

$ make -- foo
creating foo

$ make -- -
make: *** No targets.  Stop.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65759>

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

[bug #65759] handling of "-" and "--" on command line

[Paul D. Smith]

Follow-up Comment #3, bug #65759 (group make):

Yes it is a valid filename but the problem, as pointed out in the original
description, is that make doesn't treat it that way.  At least not all the
time.  It appears that the code wants to treat it as if you'd used "-f-" but
it doesn't appear to work correctly.  I do agree that this behavior is
duplicative and unpleasant.

For example:

$ make x
make: *** No rule to make target 'x'.  Stop.

but:

$ make -
make: *** No targets specified and no makefile found.  Stop.




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65759>

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

Re: [bug #65759] handling of "-" and "--" on command line

[Paul Smith]

On Mon, 2024-05-20 at 07:25 +0200, Henrik Carlqvist wrote:
> On Sun, 19 May 2024 18:02:45 -0400 (EDT)
> > Many programs use a single dash to mean "read from stdin" but make
> > doesn't
> > do this.
> 
> Yes, it does:
> 
> -8<
> nazgul:/tmp> make -f -

Yes, if you give -f (which means read from a makefile) then use "-" as
the filename it will read from stdin.

But, if you just use "make -" (without -f) then it won't read from
stdin.

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

[JZB]

On 5/19/24 18:25, Paul D. Smith wrote:

Follow-up Comment #6, bug #60736 (group make):

I think that using a warn option is better than forcing this to always warn.
But I still think that the warning makes global usage useless, and since
there's no way to control warnings on a per-target basis (today) it means the
warning is hard to use.

It seems to me that we have two different behaviors: for global .EXTRA_PREREQS
I just can't imagine anyone ever wanting to enable this warning.  Can someone
show an example of a situation where it would be useful for global
.EXTRA_PREREQS?

But for target-specific .EXTRA_PREREQS I can see how it could be useful.

So maybe what we want to do instead of (or in addition to) creating the
warning is to say that the entire behavior of omitting extra prereqs as a
prerequisite to itself only applies to global .EXTRA_PREREQS; that is in the
manual instead of:


Note @code{make} is smart enough not to add a prerequisite listed in

@code{.EXTRA_PREREQS} as a prerequisite to itself.

we make it explicit (and in the code) that this only applies to global
.EXTRA_PREREQS; something like:


Note @code{make} is smart enough not to add a prerequisite listed in a

global setting of @code{.EXTRA_PREREQS} as a prerequisite to itself.

Then we can keep all the default behaviors, including warning about circular
dependencies using the already existing warning option for this that you
proposed in the other bug, because by definition those warnings won't apply to
global .EXTRA_PREREQS due to the special case above, but they will still apply
to target-specific .EXTRA_PREREQS.

Thoughts?


As long as comment #6 is only referring to the special case of "target 
never added as a prerequisite to itself via global .EXTRA_PREREQS," then 
there is no need for the warning, because by definition there is no 
circular dependency caused by global .EXTRA_PREREQS.  So in essence, the 
situation becomes "make is not going to warn about something it didn't 
do..."  The slight clarification in the manual is thus sufficient.


But it should still warn about other circular dependencies caused  by 
users setting global .EXTRA_PREREQS, which is current behaviour already:


.EXTRA_PREREQS = a

a: b
b: c
c: d
d:
@echo making $@

$ make
make: Circular d <- a dependency dropped.
making d
make: Circular c <- a dependency dropped.
make: Circular b <- a dependency dropped.

So the corner-case of no warning for a <- a is fine, but this is where 
the choice of :warning or :error for the rest is still useful, though 
the circularity is caused by global .EXTRA_PREREQS.  It is not clear 
from the last sentence of comment #6 what the proposal is in terms what 
happens in such case.


There is one other small improvement I'd like to request in terms of 
reporting the circular dependencies, and this is almost off topic, but 
maybe it can be squeezed in to this bug, or I can open a new request, 
whatever is better:


In the make snippet above the output shows

make: Circular d <- a dependency dropped.

but what would be immensely more useful are the missing intermediate 
targets, i.e.:


make: Circular d <- c <- b <-a dependency dropped.

Tracking down circular dependencies at the moment is usually accompanied 
by digging through tons of output from the -d flag, which is 
time-consuming when all I'd really need is the [longer] cycle path itself.

Re: [bug #65759] handling of "-" and "--" on command line

[Henrik Carlqvist]

On Sun, 19 May 2024 18:02:45 -0400 (EDT)
> Many programs use a single dash to mean "read from stdin" but make doesn't
> do this.

Yes, it does:

-8<
nazgul:/tmp> make -f -
all: ; echo hello
** pressing ctrl-d on this next line **
echo hello
hello
nazgul:/tmp> make --version
GNU Make 4.1
Built for x86_64-slackware-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
nazgul:/tmp> 
-8<

regards Henrik

[bug #65759] handling of "-" and "--" on command line

[Dmitry Goncharov]

Follow-up Comment #2, bug #65759 (group make):

- is a valid filename.
i think, everybody would be better off, with one and only one syntax of having
make read from stdin.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65759>

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

[bug #65739] Add warnings circular-dep and circular-extra-dep.

[Paul D. Smith]

Follow-up Comment #3, bug #65739 (group make):

I applied the first patch (with a few tweaks).  Thanks!

Let's discuss the second patch in bug #60736 instead


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65739>

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

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

[Paul D. Smith]

Follow-up Comment #6, bug #60736 (group make):

I think that using a warn option is better than forcing this to always warn. 
But I still think that the warning makes global usage useless, and since
there's no way to control warnings on a per-target basis (today) it means the
warning is hard to use.

It seems to me that we have two different behaviors: for global .EXTRA_PREREQS
I just can't imagine anyone ever wanting to enable this warning.  Can someone
show an example of a situation where it would be useful for global
.EXTRA_PREREQS?

But for target-specific .EXTRA_PREREQS I can see how it could be useful.

So maybe what we want to do instead of (or in addition to) creating the
warning is to say that the entire behavior of omitting extra prereqs as a
prerequisite to itself only applies to global .EXTRA_PREREQS; that is in the
manual instead of:

> Note @code{make} is smart enough not to add a prerequisite listed in
@code{.EXTRA_PREREQS} as a prerequisite to itself.

we make it explicit (and in the code) that this only applies to global
.EXTRA_PREREQS; something like:

> Note @code{make} is smart enough not to add a prerequisite listed in a
global setting of @code{.EXTRA_PREREQS} as a prerequisite to itself.

Then we can keep all the default behaviors, including warning about circular
dependencies using the already existing warning option for this that you
proposed in the other bug, because by definition those warnings won't apply to
global .EXTRA_PREREQS due to the special case above, but they will still apply
to target-specific .EXTRA_PREREQS.

Thoughts?


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60736>

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

[bug #65759] handling of "-" and "--" on command line

[Paul D. Smith]

Follow-up Comment #1, bug #65759 (group make):

The behavior of "make --" is as expected because according to the POSIX
standard, the argument *--* specifies that no files after it are to be
considered options even if they begin with "-".

So for example if you wanted to make a target named *-f* you can't use *make
-f* because "-f" is a valid option name.  You'd have to use *make -- -f*.

However, I do agree that *make -* (one dash) should be considered an error. 
Many programs use a single dash to mean "read from stdin" but make doesn't do
this.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65759>

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

[bug #65759] handling of "-" and "--" on command line

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?65759>

 Summary: handling of "-" and "--" on command line
   Group: make
   Submitter: None
   Submitted: Sun 19 May 2024 02:35:54 PM UTC
Severity: 3 - Normal
      Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 19 May 2024 02:35:54 PM UTC By: Anonymous
I don't know whether this is considered a bug per se but it's pretty
confusing. Consider the following makefile:

$ cat Makefile
all:; @:$(info making $@)

$ make
making all

$ make -
making all

$ make --
making all

It seems to treat "-" and "--" as options with no effect similar to -b or -m.
However these are also considered legal target names:

$ cat Makefile
-:; @:$(info creating $@)

$ make -
creating -







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65759>

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

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

[Dmitry Goncharov]

Follow-up Comment #5, bug #60736 (group make):

Attached an alternative patch to
https://savannah.gnu.org/bugs/index.php?65739.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60736>

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

[bug #65739] Add warnings circular-dep and circular-extra-dep.

[Dmitry Goncharov]

Follow-up Comment #2, bug #65739 (group make):

Here is an example


$ cat makefile
hello: hello
$ make
make: circular hello <- hello dependency dropped
make: Nothing to be done for 'hello'.
$ make --warn=circular-dep:ignore
make: Nothing to be done for 'hello'.
$ make --warn=circular-dep:error 
make: *** circular hello <- hello dependency dropped.  Stop.
$ echo $?
2




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65739>

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

[bug #65739] Add warnings circular-dep and circular-extra-dep.

[Dmitry Goncharov]

Additional Item Attachment, bug #65739 (group make):

File name: sv65739_circular_dep_warn_part1.diff Size: 6KiB
   
<https://file.savannah.gnu.org/file/sv65739_circular_dep_warn_part1.diff?file_id=56044>

File name: sv65739_circular_dep_warn_part2.diff Size: 6KiB
   
<https://file.savannah.gnu.org/file/sv65739_circular_dep_warn_part2.diff?file_id=56045>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-0329bc976c56c39d462c6cc5223a9b3c843a6486.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65739>

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

[bug #65739] Add warnings circular-dep and circular-extra-dep.

[Dmitry Goncharov]

Follow-up Comment #1, bug #65739 (group make):

Patch sv65739_circular_dep_warn_part1.diff adds warning
circular-dep. This warning controls how makes handles circular dependencies.
The behavior is to silently drop the dependency, print a message or print a
message
and exit with an error code.
The default behavior is to print a message.

Patch sv65739_circular_dep_warn_part2.diff adds warning
circular-extra-dep. This warning is similar to circular-dep.
circular-extra-dep controls handling of circular dependencies caused by
.EXTRA_PREREQS.

This changeset is split to two commits to allow for dedicated commit messages
and provides ability to revert one of the commits, if needed.

The original user request can be found here
https://lists.gnu.org/archive/html/bug-make/2024-05/msg00013.html.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65739>

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

[bug #65739] Add warnings circular-dep and circular-extra-dep.

[Dmitry Goncharov]

URL:
  

 Summary: Add warnings circular-dep and circular-extra-dep.
   Group: make
   Submitter: dgoncharov
   Submitted: Tue 14 May 2024 01:40:55 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


___

Follow-up Comments:


---
Date: Tue 14 May 2024 01:40:55 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  

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

[bug #65737] missing intermediate target invalidates group

[Stas Sergeev]

Follow-up Comment #1, bug #65737 (group make):

Also the diagnostic doesn't consider groups.
In the above makefile example, the diagnostic is:
```
Makefile:7: update target 'b' due to: unknown reasons
```

And if `b` depends on eg `Makefile` itself (just for
the sake of an example), then the diagnostic will
misleadingly tell:
```
Makefile:7: update target 'b' due to: Makefile
```

Which is entirely wrong: update happens because of
the group invalidation, but groups seems to be
not considered by diagnostic.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65737>

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

[bug #65737] missing intermediate target invalidates group

[Stas Sergeev]

URL:
  <https://savannah.gnu.org/bugs/?65737>

 Summary: missing intermediate target invalidates group
   Group: make
   Submitter: stsp
   Submitted: Пн 13 мая 2024 19:50:35
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Пн 13 мая 2024 19:50:35   By: Stas Sergeev 
```
FILES = a b
.INTERMEDIATE: a

all: foo

$(FILES) &:
touch $(FILES)

foo: b
cat $< >$@
```

This makefile causes infinite rebuilds.
The problem is that file `a` is deleted
as being intermediate, but that mistakenly
invalidates entire group. As the result,
the targets that depend on `b` are re-built.

Missing intermediate targets should not
invalidate group.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65737>

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

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

[Dmitry Goncharov]

Follow-up Comment #3, bug #65685 (group make):


>  The way I remember it is that if we see a valid jobserver-auth argument, we
ignore the value of -j.

My understanding was that we ignore -j that comes from MAKEFLAGS, we still
honor -j specified on the command line.

> I wonder if we should simply keep the same behavior for both; if we see a
jobserver-auth on the command line we also ignore -j.

My concern is that ignoring -j specified on the command line would cause the
submake in the following example run within the parent jobserver.


all:; $(MAKE) $(MFLAGS) -j3




___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65685>

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

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

[Martin Dorey]

Follow-up Comment #10, bug #65537 (group make):

Discarding my maintMakefile patch, pulling ../gnulib, running ./bootstrap,
./configure and make worked fine now, thanks both.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65537>

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

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

[Martin Dorey]

Follow-up Comment #4, bug #65536 (group make):

Discarding my bodge here and pulling and sorting out changes from elsewhere,
the problem here appears to have gone.  Job's a good un, thanks.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65536>

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

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

[Paul D. Smith]

Follow-up Comment #2, bug #65685 (group make):

I'm not sure I get where the problem is coming from.  The way I remember it is
that if we see a valid jobserver-auth argument, we ignore the value of -j. 
This is so that we can keep the -j option in the value of MAKEFLAGS so that
users can review it.

I suppose the difference we're tracking is whether the option is passed via
the environment or via the command line?

I wonder if we should simply keep the same behavior for both; if we see a
jobserver-auth on the command line we also ignore -j.  This would still allow
people to run an explicit $(MAKE) -jN and have it do the right thing.

But that might be tricky since we'd have to understand whether the
jobserver-auth was actually on the command line or whether it came from the
environment earlier.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65685>

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

[bug #65323] Functions/shell test 22 causes ksh to crash.

[Paul D. Smith]

Update of bug #65323 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => POSIX-Based
   Fixed Release:None => SCM

___

Follow-up Comment #2:

Pushed; thanks Dmitry!


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65323>

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

[bug #65324] Fix crash in disable_builtins.

[Paul D. Smith]

Update of bug #65324 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM

___

Follow-up Comment #2:

Pushed, thank Dmitry!


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65324>

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

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

[Paul D. Smith]

Update of bug #65536 (group make):

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

___

Follow-up Comment #3:

I rewrote this entire chapter (or at least most of it).  It passes builds on
my system.  Please let me know if it still fails with older texinfo / makeinfo
environments.  I will have to figure out how to run with older versions if so.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65536>

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

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

[Paul D. Smith]

Update of bug #65537 (group make):

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

___

Follow-up Comment #9:

I pushed a change to switch GNU Make to the latest stable gnulib branch.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65537>

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

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

[Dmitry Goncharov]

Follow-up Comment #1, bug #65685 (group make):

Make adds '-j' to MAKEFLAGS and MFLAGS when -j is specified on the command
line.
When MFLAGS that contains -j is expanded in a recipe, the submake gets -j as
a command line switch. This causes submake to start its own jobserver and the
submake no longer participates in the parent jobserver.


$ ls
makefile  makefile2
$ cat makefile 
all:; $(MAKE) -fmakefile2 $(MFLAGS)
$ cat makefile2
all:;:
$ make --no-print-directory -j4
make -fmakefile2 -j4 --jobserver-auth=3,4 --no-print-directory
make[1]: warning: -j4 forced in submake: resetting jobserver mode.
:


This was recently reported to the bash mailing list.
https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00078.html.

Submakes don't need -j to participate in the top make's jobserver.
The obvious temptation is to keep MAKEFLAGS and MFLAGS free of -j.
However, -j needs to stay in MAKEFLAGS to allow makefiles to append -j to
MAKEFLAGS.
E.g. the following code needs -j in MAKEFLAGS.


MAKEFLAGS+=-j2


This patch modifies make to avoid -j in MFLAGS.
This patch keeps MAKEFLAGS intact.
Ofcourse, if the user explicitly expands MAKEFLAGS in a recipe they are back
to
the quare one. Explicitly expanding MFLAGS in a recipe is legalized in the
make manual, but explicitly expanding MAKEFLAGS is not. On top of that
explicitly expanding MAKEFLAGS has other isses, see
https://savannah.gnu.org/bugs/?62469.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65685>

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

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

[Dmitry Goncharov]

Additional Item Attachment, bug #65685 (group make):

File name: sv65685_part1.diff Size: 23KiB
<https://file.savannah.gnu.org/file/sv65685_part1.diff?file_id=56011>

File name: sv65685_part2.diff Size: 5KiB
<https://file.savannah.gnu.org/file/sv65685_part2.diff?file_id=56012>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-caa52dc0f3fa3d0ef394065c00d653c139eb10e8.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65685>

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

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?65685>

 Summary: Submake starts its own jobserver when its recipe
contains $(MAKE) $(MFLAGS) 
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 04 May 2024 08:57:53 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


___

Follow-up Comments:


---
Date: Sat 04 May 2024 08:57:53 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65685>

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

Follow-up Comment #4, bug #65588 (group make):

Indeed. Thank you. job.c changed.

Paul, do you think we can switch to git branches? i can maintain a branch
until merge. i suspect, working with a branch can be easier, than if i attach
different versions of a patch.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65588>

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Andrei Horodniceanu]

Follow-up Comment #3, bug #65588 (group make):

Your first patch (sv65588_part1.diff) doesn't apply currently. The rejected
snippet is:

--- src/job.c
+++ src/job.c
@@ -2839,7 +2841,8 @@ construct_command_argv_internal (char *line, char
**restp, const char *shell,
 return 0;
 
   if (shellflags == 0)
-shellflags = posix_pedantic && NONE_SET (flags, COMMANDS_NOERROR) ? "-ec"
: "-c";
+shellflags = defsh_flags;
+  assert (shellflags);
 
   /* See if it is safe to parse commands internally.  */
   if (shell == 0)


The rest of the patches apply fine and fix the issue for me.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65588>

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

[bug #45763] Split args along MAX_ARG_STRLEN for linux/posix

[anonymous]

Follow-up Comment #4, bug #45763 (group make):

Hello, I also encountered such an issue that make-4.3 reported "Argument list
too long". May I know whether this is fixed on master branch?


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?45763>

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

Follow-up Comment #2, bug #65588 (group make):

sv65588_part1.diff and sv65588_part2.diff fix the buffer overflow.
Make (with sv65588_part1.diff and sv65588_part2.diff applied) behaves
differently in oneshell mode compared to when .ONESHELL is not specified.
Specifically when .ONESHELL is not specified and shellflags carries an
unterminated quote, make switches to the slow mode to have the shell deal with
the
quote.


$ ls
makefile
$ cat makefile 
.SHELLFLAGS:=hello'
all:;:
$ 
$ 
$ make
:
/bin/sh: 1: Syntax error: Unterminated quoted string
make: *** [makefile:2: all] Error 2


When .ONESHELL is specified, make (with sv65588_part1.diff and
sv65588_part2.diff applied) proceeds to run the job regardless of the
unterminated quote.


$ cat makefile
.ONESHELL:
.SHELLFLAGS:=hello'
all:;:
$ make
:
/bin/sh: 0: cannot open hello': No such file
make: *** [makefile:3: all] Error 2



sv65588_part3.diff modifies construct_command_argv_internal to have oneshell
mode handle an unterminated quote the same as when .ONESHELL is not
specified.

Tested on linux, sunos and aix, all 64 and 32 bits.



___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65588>

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

Additional Item Attachment, bug #65588 (group make):

File name: sv65588_part3.diff Size: 5KiB
<https://file.savannah.gnu.org/file/sv65588_part3.diff?file_id=55953>


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-758ecd5172e512b667882c3f5b73d7b5e9a30eb0.tar.gz


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65588>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Alejandro Colomar]

Follow-up Comment #11, bug #65600 (group make):


[comment #10 comment #10:]
> You might consider checking this blog post; it describes a "common" way to
utilize silent / verbose rules.  I haven't checked the details of the Linux
man pages build system to know how much overlap etc. there is (or isn't):
> 
> https://make.mad-scientist.net/managing-recipe-echoing/

A lot.  I've learnt to write makefiles with your blog posts, and your
stackoverflow posts.  Thank you!  ;-)

Although... I stopped using $(V) in favor of --debug=print a year ago or so. 
(Which is a bit meh, because Debian Sid still ships 4.3, so I need to build
from source.  I wish someone updates that package some day.)


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65273] Potential bug in the info function?

[Paul D. Smith]

Update of bug #65273 (group make):

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

___

Follow-up Comment #10:

I have decided, for now, to keep the new behavior.  I'm open to continued
discussion.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65273>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Paul D. Smith]

Update of bug #65600 (group make):

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

___

Follow-up Comment #10:

Thanks for the comment; I will close this because I don't think we should
change this long-standing behavior of --silent.

You might consider checking this blog post; it describes a "common" way to
utilize silent / verbose rules.  I haven't checked the details of the Linux
man pages build system to know how much overlap etc. there is (or isn't):

https://make.mad-scientist.net/managing-recipe-echoing/


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65596] Test for let function not available in .FEATURES

[Paul D. Smith]

Update of bug #65596 (group make):

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

___

Follow-up Comment #3:

As Dmitry mentions most functions don't have an entry in FEATURES.  They can
almost always be detected by simply trying to invoke them and observing they
don't work.

I will say that this is becoming more difficult now that we are providing
warnings about invalid variable names (containing spaces).  We may need to
reconsider this position for future new functions, or maybe just provide a way
to get a list of defined function names.

Another option is to check for some other feature that was added in the same
release, such as 'jobserver-fifo'.  Not great I know.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65596>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Alejandro Colomar]

Follow-up Comment #9, bug #65600 (group make):

[comment #8 comment #8:]
> 
> [comment #7 comment #7:]
> 
> > You can check the build system of the Linux man-pages, which I wrote in
the last few years, if you're interested.  It's quite complex, though, so it
may be scary.  :)
> > 
> > <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>
> > 
> > The makefiles are the GNUmakefile, and files under share/mk/.
> 
> Indeed the structure seems complicated to me. I browsed a bit and I like
that you have an optional $(INFO_) that can prepend strings to the info lines
which helps (I believe) with the hierarchy of the $(info) messages from
different makefiles. 

Yep, that $(INFO_) is for recursive make(1).  Although I don't recommend
recursive make(1) at all, it is unavoidable for a very specific thing:  `make
distcheck`.  The distcheck target is supposed to run `make dist`, then extract
the tarball, and then do a few things in that extracted tarball (building, and
making sure everything's fine).

```
$ grep -rn -B4 -A2 INFO_= share/mk/
share/mk/dist/check/_.mk-26-
share/mk/dist/check/_.mk-27-distcheck-%: $(_DISTCHECKSRCDIR) $(MK) | $$(@D)/
share/mk/dist/check/_.mk-28-$(info  $(INFO_)MAKE$@)
share/mk/dist/check/_.mk-29-$(MAKE) $(_MAKE_OPTS) $* \
share/mk/dist/check/_.mk:30:'INFO_= $*: '
share/mk/dist/check/_.mk-31-
share/mk/dist/check/_.mk-32-
--
share/mk/dist/check/_.mk-34-distcheck: distcheck-diffoscope
share/mk/dist/check/_.mk-35-distcheck: $(_DISTCHECKSRCDIR) $(MK)
share/mk/dist/check/_.mk-36-$(info  $(INFO_)MAKElint build 
check install
dist)
share/mk/dist/check/_.mk-37-$(MAKE) $(_MAKE_OPTS) lint build check install
dist \
share/mk/dist/check/_.mk:38:'INFO_= distcheck:  '
share/mk/dist/check/_.mk-39-
share/mk/dist/check/_.mk-40-
--
share/mk/dist/check/dist.mk-16-
share/mk/dist/check/dist.mk-17-$(REDIST): $(_DISTCHECKSRCDIR) $(MK) | $$(@D)/
share/mk/dist/check/dist.mk-18- $(info  $(INFO_)MAKEdist-tar)
share/mk/dist/check/dist.mk-19- $(MAKE) $(_MAKE_OPTS) dist-tar \
share/mk/dist/check/dist.mk:20: 'INFO_= dist-tar:   '
share/mk/dist/check/dist.mk-21-
share/mk/dist/check/dist.mk-22-
```

> 
> > Doesn't verilator(1) allow running the compilation in a separate step? 
Maybe you can do something like this (pseudocode):
> > 
> > verilator build A >/dev/null
> > verilator run A
> > verilator build B >/dev/null
> > verilator run B
> > ...
> 
> Indeed the tool supports separating the generation of makefiles. Then I can
make(1) myself. Thanks :)

Nice.  :)

> > You could do something similar, and suffix every command with $(STDOUT),
and then (conditionally?) define STDOUT:= as an empty thing (so under normal
conditions you see the output, and optionally do the same with stderr.  When
running under verilator, you could define those variables to 1>/dev/null and
2>/dev/null.
> 
> Good idea! Thanks Alex.

You're welcome!  :-)


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Gökçe]

Follow-up Comment #8, bug #65600 (group make):


[comment #7 comment #7:]

> You can check the build system of the Linux man-pages, which I wrote in the
last few years, if you're interested.  It's quite complex, though, so it may
be scary.  :)
> 
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>
> 
> The makefiles are the GNUmakefile, and files under share/mk/.

Indeed the structure seems complicated to me. I browsed a bit and I like that
you have an optional $(INFO_) that can prepend strings to the info lines which
helps (I believe) with the hierarchy of the $(info) messages from different
makefiles. 

> Doesn't verilator(1) allow running the compilation in a separate step? 
Maybe you can do something like this (pseudocode):
> 
> verilator build A >/dev/null
> verilator run A
> verilator build B >/dev/null
> verilator run B
> ...

Indeed the tool supports separating the generation of makefiles. Then I can
make(1) myself. Thanks :)

> You could do something similar, and suffix every command with $(STDOUT), and
then (conditionally?) define STDOUT:= as an empty thing (so under normal
conditions you see the output, and optionally do the same with stderr.  When
running under verilator, you could define those variables to 1>/dev/null and
2>/dev/null.

Good idea! Thanks Alex.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Alejandro Colomar]

Follow-up Comment #7, bug #65600 (group make):


[comment #5 comment #5:]
> 
> [comment #4 comment #4:]
> 
> > Hmmm, I still disagree, because $(info) is a replacement for echo(1).  In
fact, I use .SILENCE to not show any commands, and then $(info) shows pretty
versions of them (e.g., CC file.o, instead of cc -Wall -Wextra ... -c -o
file.o file.c).
> > 
> > I could change those to use @echo, but the performance would significantly
degrade.
> 
> Your way of using .SILENCE sounds interesting, I will try that!

You can check the build system of the Linux man-pages, which I wrote in the
last few years, if you're interested.  It's quite complex, though, so it may
be scary.  :)

<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>

The makefiles are the GNUmakefile, and files under share/mk/.

> 
> I understand that $(info) is just a more efficient echo(1).

Yes.  Although being a make(1) builtin, it isn't limited to what you can
specify in a command line (ARG_MAX).  You can print an unlimited number of
words.  For debugging it's interesting.

Outside of a recipe, you can use either of the following for debugging, which
are mostly equivalent (but echo(1) has ARG_MAX limitations):

$(info $(FOO))
$(shell echo $(FOO))

> Then I could argue that they are in the same category and should be switched
off by --silent. However this would prohibit the easy way of switching of
printing the commands before executing like in your approach, which I find
also very useful. I believe my case currently does not outweigh the costs of
changing this behavior and this enhancement request can be closed in my
opinion.
> 
> > Let me ask you why you can't redirect make(1)'s output?
> 
> I use a tool called Verilator (https://verilator.org) that emits C++ code
which can compiled to a simulation binary each time when it is invoked. It
uses makefiles under the hood and it only allows me to specify -MAKEOPTS to
influence what I do with makefiles. If I would use `> /dev/null` then I would
silence whole commands output.

Doesn't verilator(1) allow running the compilation in a separate step?  Maybe
you can do something like this (pseudocode):

verilator build A >/dev/null
verilator run A
verilator build B >/dev/null
verilator run B
...

If you can't, then maybe we can do something, if you have control of your
makefiles.

I do something like that in the Linux man-pages:  there are commands that I
expect to fail under normal conditions, and I don't want to pollute the
terminal with their output.  I put $(HIDE_ERR) at the end of such commands,
which expands to 2>/dev/null.

<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/share/mk/configure/verbose.mk>
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/share/mk/dist/files.mk#n37>

You could do something similar, and suffix every command with $(STDOUT), and
then (conditionally?) define STDOUT:= as an empty thing (so under normal
conditions you see the output, and optionally do the same with stderr.  When
running under verilator, you could define those variables to 1>/dev/null and
2>/dev/null.





___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Gökçe]

Follow-up Comment #6, bug #65600 (group make):

I could not find a button to close this enhancement request. I assume I don't
have any privileges. Feel free to close this item.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Gökçe]

Follow-up Comment #5, bug #65600 (group make):


[comment #4 comment #4:]

> Hmmm, I still disagree, because $(info) is a replacement for echo(1).  In
fact, I use .SILENCE to not show any commands, and then $(info) shows pretty
versions of them (e.g., CC file.o, instead of cc -Wall -Wextra ... -c -o
file.o file.c).
> 
> I could change those to use @echo, but the performance would significantly
degrade.

Your way of using .SILENCE sounds interesting, I will try that!

I understand that $(info) is just a more efficient echo(1). Then I could argue
that they are in the same category and should be switched off by --silent.
However this would prohibit the easy way of switching of printing the commands
before executing like in your approach, which I find also very useful. I
believe my case currently does not outweigh the costs of changing this
behavior and this enhancement request can be closed in my opinion.

> Let me ask you why you can't redirect make(1)'s output?

I use a tool called Verilator (https://verilator.org) that emits C++ code
which can compiled to a simulation binary each time when it is invoked. It
uses makefiles under the hood and it only allows me to specify -MAKEOPTS to
influence what I do with makefiles. If I would use `> /dev/null` then I would
silence whole commands output.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Alejandro Colomar]

Follow-up Comment #4, bug #65600 (group make):

Hi Gökçe,

[comment #3 comment #3:]
> 
> [comment #2 comment #2:]
> > No.  --silent (and .SILENT) don't silence the output of any command. 
Where did you get that from?
> > No.  `@` is to not print the command before executing it.  For silencing
the command, you'd need to >/dev/null
> 
> I made a mistake in my wording — I apologize. What I meant was *the
command before executing*.

Ahh, okay, that makes sense.

> > Use `echo ... >/dev/null`, although I don't know why you'd want to silence
echo(1).  If you don't want echo(1), just remove it.
> 
> You are right, in the end make should not have any effect on the output of
the executed commands.
> 
> > If you want to silence make(1), you can `make >/dev/null`.
> 
> In my case I only have access to `--silent` but cannot redirect the output
of `make`. Just one case does not justify my proposal — however the concept
of *silencing* is about *severity* of messages and I like that `--silent` can
suppress the commands being executed. I just propose that `$(info)` could be
included too, because `$(info)` is part of make and not a executed command.

Hmmm, I still disagree, because $(info) is a replacement for echo(1).  In
fact, I use .SILENCE to not show any commands, and then $(info) shows pretty
versions of them (e.g., CC file.o, instead of cc -Wall -Wextra ... -c -o
file.o file.c).

I could change those to use @echo, but the performance would significantly
degrade.

Let me ask you why you can't redirect make(1)'s output?

Have a lovely day!
Alex


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Gökçe]

Follow-up Comment #3, bug #65600 (group make):


[comment #2 comment #2:]
> No.  --silent (and .SILENT) don't silence the output of any command.  Where
did you get that from?
> No.  `@` is to not print the command before executing it.  For silencing the
command, you'd need to >/dev/null

I made a mistake in my wording — I apologize. What I meant was *the command
before executing*.

> Use `echo ... >/dev/null`, although I don't know why you'd want to silence
echo(1).  If you don't want echo(1), just remove it.

You are right, in the end make should not have any effect on the output of the
executed commands.

> If you want to silence make(1), you can `make >/dev/null`.

In my case I only have access to `--silent` but cannot redirect the output of
`make`. Just one case does not justify my proposal — however the concept of
*silencing* is about *severity* of messages and I like that `--silent` can
suppress the commands being executed. I just propose that `$(info)` could be
included too, because `$(info)` is part of make and not a executed command.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65600] `--silent` option should also silence `$(info ...)`

[Alejandro Colomar]

Follow-up Comment #2, bug #65600 (group make):


[comment #0 original submission:]
> Currently `--silent` option only silences the output of the executed
commands.

No.  --silent (and .SILENT) don't silence the output of any command.  Where
did you get that from?

> Some users of make use `echo` or `$(info ..)` to summarize what is being
done in a recipe and use `@` to silence the executed commands.

No.  `@` is to not print the command before executing it.  For silencing the
command, you'd need to >/dev/null

> However it is not possible to silence `echo` or `$(info ..)`. 

Use `echo ... >/dev/null`, although I don't know why you'd want to silence
echo(1).  If you don't want echo(1), just remove it.

> IMHO silencing the output is important in user-facing applications that
still make use of makefiles, e.g., an application that creates a simulation
binary from provided code.
> 
> I propose that `--silence` should include `$(info ..)`, but not `$(warning
..)` and `$(error ..)`. What do you think?

No.

If you want to silence make(1), you can `make >/dev/null`.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65600>

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

[bug #65596] Test for let function not available in .FEATURES

[Dmitry Goncharov]

Follow-up Comment #2, bug #65596 (group make):

Other functions are not present in .FEATURES as well. There is really only
guile.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65596>

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