[bug #61076] gmake incorrectly implements Pattern Replacement Macro References

URL: Summary: gmake incorrectly implements Pattern Replacement Macro References Project: make Submitted by: schily Submitted on: Mon 23 Aug 2021 11:28:37 PM UTC Severity: 3 - Normal

[bug #59399] Add a warning about using $* and $< in explicit rules

Follow-up Comment #6, bug #59399 (project make): I would love to see gmake to avoid unneeded and confusing output. I however see tons of messages like 'entering directory..' and similar. If you like to see these kind of messages, I would expect that people need to use a related option to enable

[bug #59395] gmake space handling is not compatible to POSIX

Follow-up Comment #2, bug #59395 (project make): Could you explain why gmake deviates from make in such an important point? I believe that .POSIX should be reserved to cases where the POSIX standard does not agree with the behavior of the historic UNIX make. This however does not apply to this

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

Follow-up Comment #10, bug #58734 (project make): I am sorry, but there are problems in gmake that only show up with large or complex makefiles. I cannot give simpler examples as I cannot spend an infinite amount of time in trying to find a smaller example. I however already explained to you how

[bug #59399] Expanding implicit macros in gmake (enhancement request)

Follow-up Comment #3, bug #59399 (project make): Let me add a hint... I just verified that expanding $< and $* for explicit rules at all was an invention from SunPro Make. These macros have not been expanded by the classical UNIX make.

[bug #59399] Expanding implicit macros in gmake (enhancement request)

Follow-up Comment #2, bug #59399 (project make): Well, it may be a bit confusing because I am maintaining two make implementations. 1) The program smake, I wrote in the early 1980s and that is still maintained. 2) The SunPro Make program that Sun made OSS on my request in December 2006.

[bug #57751] Improve POSIX support for SCCS

Follow-up Comment #16, bug #57751 (project make): Just in case that helps, the syntax of the make language is not written down cleanly as a compact syntax description in the POSIX standard. You need to read a lot of the general text. My explanations about the expansions of macros at parse time

[bug #57751] Improve POSIX support for SCCS

Follow-up Comment #14, bug #57751 (project make): Please read my previous answer... Any dependency line in e.g. the form: $(TGT): $(DEPS) is completely expanded at the time the parser reads the makefile, so in this example, $(TGT) and $(DEPS) already need to have a value at the time, the

[bug #57751] Improve POSIX support for SCCS

Follow-up Comment #12, bug #57751 (project make): Re: comment #8: you are mistaken. gmake has some deviations from POSIX and a classical UNIX make but these deviations are *much* less important than the deviations found in bmake. The BSD make program is not related to any UNIX make program, it

[bug #57751] Improve POSIX support for SCCS

Follow-up Comment #7, bug #57751 (project make): Just a note to the XSI "enhancements" to POSIX Implementing all XSI enhancements is required in order to get the permission to call a platform "UNIX" compatible and thus to use the UNIX trademark. A platform that implements support for XSI is

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #3, bug #58556 (project make): printf 'MAKEFLAGS=r \n .SUFFIXES:' | make - .o is completely ineffective and printf 'MAKEFLAGS=r \n .SUFFIXES:' | make -f - .o is ineffective because MAKEFLAGS=r is read after the internal makefile was read. BTW: it s bad practice to set

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #1, bug #58556 (project make): Any make implementation reads the internal make definitions before reading any normal makefile. Your observed behavior is expected behavior. ___ Reply to this item at:

[bug #59399] Expanding implicit macros in gmake (enhancement request)

URL: Summary: Expanding implicit macros in gmake (enhancement request) Project: make Submitted by: schily Submitted on: Mon 02 Nov 2020 01:36:37 PM UTC Severity: 3 - Normal

[bug #59247] function shell eats a newline

Follow-up Comment #2, bug #59247 (project make): I am not sure whether your patch is the right fix. Your bug may be related to bug 59395, I reported recently, but your patch does not fix the problem in bug 59395. In general, gmake has several oddities in the area of handling space, tab, newline

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #16, bug #59154 (project make): Hi Dan, using BSD make as an example in general is not a good idea since BSD make implements plenty of non-POSIX compliant "features". Since this command however works fine with SunPro Make and smake and produces the same output as bmake, it

[bug #59395] gmake space handling is not compatible to POSIX

URL: Summary: gmake space handling is not compatible to POSIX Project: make Submitted by: schily Submitted on: Sun 01 Nov 2020 07:41:16 PM UTC Severity: 3 - Normal Item

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

Follow-up Comment #8, bug #58734 (project make): Sorry for the typo, the command in step 8 of course should be: find . -type l -exec rm {} + ___ Reply to this item at:

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

Follow-up Comment #7, bug #58734 (project make): You are mistaken. My makefile describes enough of the files to allow any non-buggy make implementation to work correctly. If gmake does not check the state of a file before it claims that this file is missing, then gmake is broken. Steps to

[bug #58735] When rebuilding makefiles, make tries them in reverse order

Follow-up Comment #4, bug #58735 (project make): If I provide more dependency information, gmake runs more commands in parallel when in parallel mode and this will cause more problems since only one of these commands needs to be run. So this is also a problem that is related to an unhappy

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

Follow-up Comment #5, bug #58734 (project make): I forgot to mention, that this happens in parallel and in serial mode. So your assumption is wrong. Caching is not a bad thing if it helps to speed up things. I did not make related tests and I am not going to doubt here because this would put

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

Follow-up Comment #4, bug #58734 (project make): This is one of the gmake bugs that does not seem to exist with trivial makefiles. This is why I am apparently unable to give a small example to repeat that problem. If you really need a makefile to repeat the problem, I can give you a modified

[bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order

Follow-up Comment #2, bug #58735 (project make): Thank you for confirming that gmake executes the commands for out of date targets that result from the include directive in the inverse (which is the wrong) order. This wrong order causes gmake or the compiler to try to access files that have not

[bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order

URL: Summary: if depending on include, gmake does not execute commands for out of date targets in the right order Project: make Submitted by: schily Submitted on: Wed 08 Jul 2020 03:10:27 PM UTC

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

URL: Summary: gmake does not check for the existence of a file before complaining it is missing Project: make Submitted by: schily Submitted on: Wed 08 Jul 2020 02:59:25 PM UTC