[bug #60297] optimize autodeps

Follow-up Comment #2, bug #60297 (project make): sv60297_notintermediate_test.diff is a test. ___ Reply to this item at: ___ Message sent via Savannah

[bug #60297] optimize autodeps

Follow-up Comment #4, bug #60297 (project make): Typo. sv60297_notintermediate.diff contains implementation of special target *.NOTINTERMEDIATE.* ___ Reply to this item at:

[bug #60297] optimize autodeps

Follow-up Comment #3, bug #60297 (project make): sv60297_notintermediate_doc.diff is a doc. ___ Reply to this item at: ___ Message sent via Savannah

[bug #60297] optimize autodeps

Follow-up Comment #6, bug #60297 (project make): The modern technique of tracking dependencies uses include directive. While this technique is infinitely superior to the manual maintenance of deps there is still room for improvement. 1. include is not a part of the dag. src:=$(wildcard *.c)

[bug #60297] optimize autodeps

Follow-up Comment #5, bug #60297 (project make): i noticed that something messed up tabs in the examples in the original submission. Please disregard original submission. Let me resubmit. ___ Reply to this item at:

[bug #60297] optimize autodeps

URL: Summary: optimize autodeps Project: make Submitted by: dgoncharov Submitted on: Sun 28 Mar 2021 01:06:47 AM UTC Severity: 3 - Normal Item Group: Enhancement

[bug #60312] echo replaces double quote with backslash

Follow-up Comment #1, bug #60312 (project make): Make passes recipies to shell line by line. Shell runs echo. You can see here echo 'nospacebefore:"xx"' nospacebefore:\xx" The first line is what make passes to shell. The 2nd line is the result of echo. Apparently, echo on your system does this.

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

Follow-up Comment #1, bug #60281 (project make): This is a duplicate of https://savannah.gnu.org/bugs/index.php?57962. ___ Reply to this item at: ___

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Follow-up Comment #4, bug #60188 (project make): Thank you, Paul. 1. Do you mean something like CC="@echo cc" ? 2. sure 3. By the old style do you mean run_make_with_options? ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_explicit_intermediate_test.diff Size:0 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Follow-up Comment #5, bug #60188 (project make): Paul, i attached one more test sv60188_explicit_intermediate_test.diff. This one tests that an explicitly mentioned file is still intermediate when it is a prereq to .INTERMEDIATE. ___

[bug #60188] Explicit file built by an implicit rule is not intermediate.

URL: Summary: Explicit file built by an implicit rule is not intermediate. Project: make Submitted by: dgoncharov Submitted on: Sun 07 Mar 2021 07:02:23 PM UTC Severity: 3 - Normal

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_explicit_file_built_by_implicit_rule_is_not_intermediate.diff Size:5 KB

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_patternrules_test.diff Size:2 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_double_colon_test.diff Size:0 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_statipattrules_test.diff Size:0 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_grouped_targets_test.diff Size:0 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_se_implicit_test.diff Size:1 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Follow-up Comment #1, bug #60188 (project make): sv60188_explicit_file_built_by_implicit_rule_is_not_intermediate.diff contains a fix. All other attached patches contain new tests. Even though the fix is not related to static pattern rules, i added a test for static pattern rules to cover all

[bug #60378] Avoid duplicates in default_include_directories.

Additional Item Attachment, bug #60378 (project make): File name: sv60378_no_dups_in_default_include_directories.diff Size:1 KB ___

[bug #60378] Avoid duplicates in default_include_directories.

URL: Summary: Avoid duplicates in default_include_directories. Project: make Submitted by: dgoncharov Submitted on: Mon 12 Apr 2021 01:19:21 AM UTC Severity: 3 - Normal

[bug #60378] Avoid duplicates in default_include_directories.

Follow-up Comment #1, bug #60378 (project make): The patch in the attachments compares the value of prefix with one of the hardcoded defaults of default_include_directories and defines INCLUDEDIR only if the specified prefix is different.

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

Follow-up Comment #3, bug #47880 (project make): > The change I have allows someone to reset the search path from within the makefile Awesome. i personally, need this change to be able to skip the default search directories. > In make generally (and, IMO, correctly) the person invoking make

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

Follow-up Comment #5, bug #47880 (project make): > The problem is that MAKEFLAGS is only parsed once before all makefiles are read, and again after all makefiles are read. So, this all boils down to having make consider changes to MAKEFLAGS immediately. > I was hoping to avoid adding a new

[bug #60412] Avoid default include directories when searching for included files.

URL: Summary: Avoid default include directories when searching for included files. Project: make Submitted by: dgoncharov Submitted on: Sat 17 Apr 2021 08:34:55 PM UTC Severity: 3 -

[bug #60412] Avoid default include directories when searching for included files.

Additional Item Attachment, bug #60412 (project make): File name: sv60412_dash_a_test.diff Size:0 KB File name: sv60412_dash_a_doc.diffSize:1 KB

[bug #60412] Avoid default include directories when searching for included files.

Additional Item Attachment, bug #60412 (project make): File name: sv60412_dash_a.diffSize:3 KB ___ Reply to this item at:

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

URL: Summary: Document phony order-only prerequisites. Project: make Submitted by: dgoncharov Submitted on: Sat 21 Aug 2021 09:17:13 PM UTC Severity: 3 - Normal Item

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

Additional Item Attachment, bug #61069 (project make): File name: sv_61069_document_orderonly_beats_phony.diff Size:0 KB ___ Reply to

[bug #61042] Enhance implicit rule search logging

Additional Item Attachment, bug #61042 (project make): File name: sv_61042_reuse_rule_name_for_dash_p.diff Size:0 KB ___ Reply to this item

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #2, bug #61042 (project make): sv_61042_reuse_rule_name_for_dash_p.diff reuses rule->name for printing the db under -p. ___ Reply to this item at:

[bug #61042] Enhance implicit rule search logging

Additional Item Attachment, bug #61042 (project make): File name: sv_61042_implicit_rule_search_logging.diff Size:13 KB ___ Reply to this

[bug #61042] Enhance implicit rule search logging

URL: Summary: Enhance implicit rule search logging Project: make Submitted by: dgoncharov Submitted on: Sun 15 Aug 2021 04:11:25 AM UTC Severity: 3 - Normal Item Group:

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #1, bug #61042 (project make): sv_61042_implicit_rule_search_logging.diff has the following Changes in the implicit rule search logging: 1. The messages which refer to a rule print the first line (the targets and prerequisites) of the rule. 2. A new message tells when a

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

Follow-up Comment #5, bug #52922 (project make): > Maybe this enhancement (using a separate lock file for submakes that are redirected) is something that simply won't be supported on those systems as the effort is not worth the reward. This confuses users on linux as well.

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

Follow-up Comment #4, bug #52922 (project make): There was a recent discussion about this. See https://savannah.gnu.org/bugs/?60774 and the mailing list. ___ Reply to this item at:

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

Follow-up Comment #10, bug #52922 (project make): > I considered fixing that in FreeBSD, but I'm running build farm stuff across a bunch of OSes that all have this problem hence desire to fix it here. Gentlemen, can you please describe the state of affairs in the bsd world in regards to gnu

[bug #61122] Add a .SECONDARY example.

Additional Item Attachment, bug #61122 (project make): File name: sv_61122_doc_secondary_example.diff Size:1 KB ___ Reply to this item at:

[bug #61122] Add a .SECONDARY example.

Follow-up Comment #3, bug #61122 (project make): A bit more context about this patch. Recently a person showed me a makefile with an incorrect use of .SECONDARY. When i asked about this, the person explained, that there is no example of when .SECONDARY is useful.

[bug #61122] Add a .SECONDARY example.

URL: Summary: Add a .SECONDARY example. Project: make Submitted by: dgoncharov Submitted on: Mon 06 Sep 2021 02:35:26 PM UTC Severity: 3 - Normal Item Group:

[bug #61122] Add a .SECONDARY example.

Follow-up Comment #2, bug #61122 (project make): Well, i thought it was obvious that this applies when hello.tsk exists and is up to date in regards to hello.c and bye.c. But apparently, this is not obvious. i applied another patch which explicitly states when this applies. (file #51875)

[bug #60399] Incorrect dependencies with grouped targets

Follow-up Comment #3, bug #60399 (project make): There is this difference in behavior between the 2 makefiles. In the cause of .PHONY: b a b&:; touch a b b is phony and a is not phony. In the case of .PHONY: force b: force a b&:; touch a b Both a and b depend on force. Do you think make

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

Follow-up Comment #3, bug #61328 (project make): > my argument is that it can assume paths ending in the path separator are directories since they can't be anything else: This assumption looks reasonable. What change in behavior do you think is appropriate with this assumption?

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

Follow-up Comment #1, bug #61328 (project make): > However, since "foo/" is illegal for anything but a directory it seems harmless to assume directory. This special case could also be made to apply exclusively to order-only prerequisites which is where directory dependencies should be anyway. It

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

Follow-up Comment #8, bug #61226 (project make): > > Switching to -include robs the user of a useful message, should there be a real issue. > I'm not sure what this means: in what situation do we lose a useful message? -include robs the user of a not readable or corrupted .d file, even though

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #3, bug #61042 (project make): Another scenario that i noticed, when this enhanced logging helps, is when the source file is present, but vpath is incorrect. E.g. vpath %.cpp %.c $(srcdir). Again make ignores the rule, because it cannot find the source file, but gives no

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #8, bug #61042 (project make): Merged master to my branch and resolved the conflict in patch sv_61042_implicit_rule_search_logging2.diff. The same change is also available here g...@github.com:dgoncharov/make.git on branch sv61042_enhance_implicit_search_logging. (file

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #7, bug #61042 (project make): There are 2 situations when implicit rule lookup takes this short cut. 1. hello.tsk: hello.o %.tsk: %.o; touch $@ and 2. hello.tsk: %.tsk: %.o; touch $@ hello.o: There are 2 if branches in implicit.c This branch handles

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

Follow-up Comment #3, bug #61226 (project make): i agree, this is a special case. imo, empty vs not empty is okay for make to consider, given that make manual documents this special behavior when the recipe or prerequisites are empty and the file is missing. This is in sharp contract with the

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

Follow-up Comment #1, bug #61226 (project make): This is an example of the failure $ ls makefile $ cat makefile hello.o: hello.d; touch $@ $< hello.d:; include hello.d $ make makefile:3: hello.d: No such file or directory $ echo $? 2 ___

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

Follow-up Comment #6, bug #61226 (project make): It is disturbing that the warning is printed each time a .d file is missing. In other words, make prints a warning in an everything goes as planned situation, like a clean build. Switching to -include robs the user of a useful message, should there

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

Follow-up Comment #5, bug #61226 (project make): > When you say the special behavior do you mean the section "Rules without Recipes or Prerequisites"? exactly > I think that text is a little misleading. There's actually nothing magical about having no recipe or an empty recipe here, as best

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

Additional Item Attachment, bug #61226 (project make): File name: sv_61226_no_build_on_missing_includes.diff Size:1 KB ___ Reply to this

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

URL: Summary: A regression prevents generation of missing included dependency files. Project: make Submitted by: dgoncharov Submitted on: Sun 26 Sep 2021 02:34:37 PM UTC Severity: 3

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

Additional Item Attachment, bug #61226 (project make): File name: sv_61226_no_build_on_missing_includes.diff Size:2 KB File name: sv_61226_no_build_on_missing_includes_test.diff Size:3 KB

Re: Compilation error with GCC

On Sun, Dec 19, 2021 at 1:51 PM Mohammad Akhlaghi wrote: > The configuration went nicely, however, during the compilation it > crashed with the attached error. i think, Jouke provided patches to workaround this warning. You can pass a flag to gcc to not treat warnings as errors. e.g. $ make

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

Follow-up Comment #17, bug #48643 (project make): Thank you, Steven. ___ Reply to this item at: ___ Message sent via Savannah

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

Additional Item Attachment, bug #48643 (project make): File name: sv48643_fix2.diff Size:8 KB File name: sv48643_test2.diff Size:12 KB

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

Follow-up Comment #18, bug #48643 (project make): Attached sv48643_fix2.diff and sv48643_test2.diff. sv48643_test2.diff contains two new tests compared to sv48643_test.diff.. These new tests require that compatibility search builds intermediates. sv48643_fix2.diff has two changes compared to

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

Follow-up Comment #15, bug #48643 (project make): > Are you saying that this also should be the correct behaviour? I now realize, that inadequate description of example 3 was provided and caused misunderstanding. Let me provide a more verbose description. Make has to do both skip unrelated

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

Follow-up Comment #22, bug #48643 (project make): > If I add a note when we start the compatibility check, it shows up here (obviously we'd pick a more informative note if we added this): ... > I guess it's appropriate here but it seemed odd to me. i also think, it is appropriate here. Does the

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

Follow-up Comment #4, bug #55242 (project make): i agree that the makefile in question is incorrect. i don't think the patch should be applied. i should not have provided the patch to begin with. i'd just gave the 'a.mk: b' rule a proper recipe which builds 'a.mk', rather than an empty recipe.

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

Follow-up Comment #20, bug #48643 (project make): Thank you, Paul. The user may not realize that their makefile relies on compatibility search and the related performance penalty. Do you think it is appropriate to print a message when make begins compatibility search to let the user know?

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #10, bug #61042 (project make): Thank you, Paul. Does the leading underscore in rule->_defn has a special meaning, follow gnu make convention or similar? ___ Reply to this item at:

[bug #61042] Enhance implicit rule search logging

Follow-up Comment #12, bug #61042 (project make): > I used it because I wanted to mark that data member as being "private" in the sense that it shouldn't be used directly by other parts of the code; instead the get_rule_defn() function should always be called to retrieve that value. Good to

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

Follow-up Comment #23, bug #48643 (project make): Yet another option is to have compatibility search disabled by default and introduce flag '--enable-compatibility-search'. This is a good choice going forward, because we really don't want new makefiles to rely on compatibility search. This choice

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

Follow-up Comment #5, bug #60799 (project make): > But my point is that $$ is NOT (intended to be) special to make. That's why make doesn't do parentheses matching which it sees it. Sure, we can adopt this stance and say no parentheses matching for $$. i am not sure this behavior is the most

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

Additional Item Attachment, bug #48643 (project make): File name: sv48643_test.diff Size:10 KB File name: sv48643_doc.diff Size:1 KB

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

Follow-up Comment #12, bug #48643 (project make): Let us say hello.c is missing, hello.f is present in the filesystem and consider the following example Example 1. all: hello.tsk %.tsk: %.c; $(info $@ from $<) %.tsk: %.f; $(info $@ from $<) unrelated: hello.c The current behavior is

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

Follow-up Comment #13, bug #48643 (project make): Added 4 patches. fix, test, doc and news. The same changeset can be found in repo g...@github.com:dgoncharov/make.git on branch sv48643_retry_compat_rules. ___ Reply to this item at:

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

Additional Item Attachment, bug #48643 (project make): File name: sv48643_preserve_target_specific_vars_of_interm_test.diff Size:2 KB File name:

Re: .SECONDEXPANSION problems

On Sun, Dec 12, 2021 at 2:15 PM Paul Smith wrote: > Did something happen when it stopped working, like you updated to a > different version of GNU make? i bet this make is built from the current git. > Can you create a small, self-contained example that shows the problem you're > seeing? i

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

Follow-up Comment #28, bug #48643 (project make): Let us consider Example 7. all: hello.tsk %.tsk: hello.x; $(info $@) %.x:; $(flags) hello.x: flags:=true Here 'hello.x' has a target specific variable 'flags' with value 'true'. Setting a target specific variable causes make to enter

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

URL: Summary: Add a startup optimizaton hint to the manual. Project: make Submitted by: dgoncharov Submitted on: Sun 05 Dec 2021 09:56:47 PM UTC Severity: 3 - Normal

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

Additional Item Attachment, bug #61623 (project make): File name: sv61623_doc.diff Size:1 KB ___ Reply to this item at:

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

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

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

Additional Item Attachment, bug #48643 (project make): File name: sv48643_exp_preqreq_is_not_interm_tests.diff Size:4 KB File name: sv48643_exp_preqreq_is_not_interm.diff Size:1 KB

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

Follow-up Comment #27, bug #48643 (project make): i figured this change is still incomplete. There is a case when make marks this almost-ought-to-exist prerequisite as intermediate incorrectly. Let us say hello.tsk exists and hello.x is missing and consider Example 6. all: hello.tsk

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

Follow-up Comment #25, bug #48643 (project make): Let us list the options 1. keep compat search enabled by default and silent. 2. introduce a warning message when make begins compat search. 3. introduce a flag to disable compat search. 4. have compat disabled by default and introduce a flag to

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

Follow-up Comment #7, bug #60774 (project make): The windows code, which passes down the semaphore to children is reused to pass down the fd on unix. > The way you propose to reuse the Windows code brings that Windows-specific stuff back into view. it is not clear to me what windows specific

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

Follow-up Comment #3, bug #60774 (project make): i pushed a fix here https://github.com/dgoncharov/make/tree/sv_60774_output_sync_deadlock. This fix does the following. Lock a temp file to synchronize output. 1. Lock a temp file, rather than stdout, to synchronize output. Locking stdout

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

Follow-up Comment #4, bug #60774 (project make): In your case, Mike, you can either try this fix or find the offending process with lsof and kill it. ___ Reply to this item at:

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

Follow-up Comment #2, bug #60774 (project make): Thanks for your report, Mike. make uses file locking on stdout to synchronize output. int fd = fileno(STDOUT); fcntl (fd, F_SETLKW, ); After fcntl return make prints its output. In your case another process has /dev/null locked. With make's

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

Follow-up Comment #9, bug #60774 (project make): i was able to test on windows and attached a proposed patch. The patch does what is described in update 3. ___ Reply to this item at:

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

Additional Item Attachment, bug #60774 (project make): File name: sv_60774_output_sync_deadlock_fix.diff Size:6 KB ___ Reply to this item at:

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

Additional Item Attachment, bug #60774 (project make): File name: sv_60774_output_sync_deadlock_fix2.diff Size:6 KB ___ Reply to this item at:

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

On Thu, Jan 6, 2022 at 2:13 PM Alejandro Colomar (man-pages) wrote: > I could try to write a simpler Makefile That would be good. We need to be able to reproduce the crash. regards, Dmitry

Re: escaped newline in macro expansion in command line

On Fri, Dec 24, 2021 at 6:30 PM Humm wrote: > That’s the argument I’m making. Humm, in the following example do you want N and M to expand to different values? If yes, can you please tell us about your use case where such behavior is needed? .POSIX: M=word N=${M:word=a\ b} all:; echo ${N}

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

Follow-up Comment #3, bug #61805 (project make): Here is a better version of the fix and more tests in sv61805_fix2.diff and sv61805_test2.diff. (file #52664, file #52665) ___ Additional Item Attachment: File name: sv61805_test2.diff

Re: escaped newline in macro expansion in command line

On Fri, Jan 7, 2022 at 11:32 AM Dmitry Goncharov wrote: > If we can agree, then i'll file a request to opengroup to explicitly > state that this > > "When an escaped is found in a command line in a makefile, > the command line shall contain the , the , and the > next line

Re: .SILENT: clobbered by .SILENT: with_target

On Tue, Jan 11, 2022 at 3:50 PM Britton Kerin wrote: > It looks like the .SILENT: with a recipe clobbers the .SILENT: > without Consider the following hello.tsk: hello.tsk: hello.h hello.tsk: hello.o; $(CC) -o $@ $< Here, hello.tsk is the default goal and it depends on hello.o and hello.h.

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

Follow-up Comment #1, bug #61805 (project make): There is a dedicated piece of code in job.c for oneshell. This dedicated piece of code tokenizes the contents of shellflags by white space. ___ Reply to this item at:

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

Follow-up Comment #2, bug #61805 (project make): The patch in the attachment has a fix against the current master and a test. (file #52654, file #52655) ___ Additional Item Attachment: File name: sv61805_test.diff Size:0 KB

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

URL: Summary: .ONESHELL causes quoting in .SHELLFLAGS to not work as expected. Project: make Submitted by: dgoncharov Submitted on: Thu 13 Jan 2022 12:53:17 AM UTC Severity: 3 -

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

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

[bug #62173] Fix test features/archives.

Follow-up Comment #2, bug #62173 (project make): The patch contains the following changes -my $arflags = 'rv'; +my $arflags = '-rv'; +if ($^O eq 'aix') { +$arflags = "-Xany -rv"; +} That reason for the first part of the patch, specifically -my $arflags = 'rv'; +my $arflags =

[bug #62145] Unlink the stdin temporary file on failure to re-execute.

URL: Summary: Unlink the stdin temporary file on failure to re-execute. Project: make Submitted by: dgoncharov Submitted on: Sun 06 Mar 2022 07:36:16 PM UTC Severity: 3 - Normal

[bug #62145] Unlink the stdin temporary file on failure to re-execute.

Additional Item Attachment, bug #62145 (project make): File name: sv62145_test.diff Size:4 KB File name: sv62145_fix.diff Size:2 KB

Re: [bug #62118] Fix parsing of command line options -f, --file, --makefile.

On Sun, Feb 27, 2022 at 6:11 PM Paul D. Smith wrote: > > Update of bug #62118 (project make): ... > When looking at the test results I noticed that we were leaving the temporary > files behind if we had to re-exec, because the re-exec'd version of make > didn't realize they were temporary. > > I

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

Follow-up Comment #2, bug #62162 (project make): You can store % in a variable percent:=% $(files) : %.ext : $$(patsubst r$(percent),$(percent),$$(lastword $$(subst .stem., ,$$*)))-prereq ___ Reply to this item at:

<    1   2   3   4   5   6   7   >