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

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

Follow-up Comment #9, bug #47880 (project make): > But, maybe it's better to grab that bull by the horns. >From the user's point of view, it may indeed be better to have a single interface (MAKEFLAGS), which controls the behavior from the makefile. > Regarding removing default directories, I won

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

Additional Item Attachment, bug #60435 (project make): File name: sv60435_fix.diff Size:3 KB File name: sv60435_doc.diff Size:0 KB

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

Follow-up Comment #1, bug #60435 (project make): i attached 3 patches, the fix, tests and a fix in the doc. Thanks for your report. ___ Reply to this item at: __

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

Follow-up Comment #11, bug #47880 (project make): > Can you use this?: > include $(CURDIR)/foo.mk This indeed suppresses the lookup. My opinion is that the users should not have to know this detail. The behavior should preferably be optimial for the most common scenarios. Also, most (as far as

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

Follow-up Comment #13, bug #47880 (project make): > > My opinion is that the users should not have to know this detail. > I didn't realize you were wearing your 'user' hat! My bad. By "users" here (and in other places) i meant make users, people who write makefiles. In other words, when a user

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

Follow-up Comment #1, bug #60595 (project make): Can you please attach a makefile which reproduces the issue? ___ Reply to this item at: ___ Сообщение

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

URL: Summary: Incorrect 2nd expansion of $$< inside a function in the prerequisite list. Project: make Submitted by: dgoncharov Submitted on: Sun 23 May 2021 02:26:36 PM UTC Severity:

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

Additional Item Attachment, bug #60659 (project make): File name: sv60659_fix.diff Size:0 KB File name: sv60659_test_implicit.diff Size:3 KB

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

Follow-up Comment #1, bug #60659 (project make): Attached tests of explicit and implicit rules and a fix. ___ Reply to this item at: ___ Message sent v

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

Follow-up Comment #3, bug #60659 (project make): Sure, will do. Thanks for review. ___ Reply to this item at: ___ Message sent via Savannah https://s

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

URL: Summary: Avoid calling strlen repeatedly in a loop. Project: make Submitted by: dgoncharov Submitted on: Sun 30 May 2021 12:08:15 AM UTC Severity: 3 - Normal Item G

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

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

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

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

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

Follow-up Comment #2, bug #60699 (project make): Sure, here is a unified diff. Rather than attaching diffs, we could submit git branches for review. What do you think? ___ Reply to this item at: _

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

URL: Summary: Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps. Project: make Submitted by: dgoncharov Submitted on: Sun 06 Jun 2021 01:33:46 AM UTC Severity: 3 -

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

Follow-up Comment #1, bug #60736 (project make): With the patch in the attachment the output is $ make -f makefile2 make: Circular hello.x <- hello.x dependency dropped. touch hello.x $ ___ Reply to this item at:

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

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

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

Follow-up Comment #5, bug #60077 (project make): Todd, thank for your contribution. Your patch is missing second expansion tests. i observe the following misbehavior. $ cat makefile .SECONDEXPANSION: hello world&: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^)) $(info in recipe

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

URL: Summary: Command line switch --trace disables -d. Project: make Submitted by: dgoncharov Submitted on: Sun 13 Jun 2021 09:16:10 PM UTC Severity: 3 - Normal Item Gro

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

Additional Item Attachment, bug #60777 (project make): File name: sv_60777_fix.diff Size:0 KB File name: sv_60777_test.diff Size:0 KB

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

URL: Summary: Parser chokes on second expansion of a prerequisite with ; o # Project: make Submitted by: dgoncharov Submitted on: Sat 19 Jun 2021 01:41:58 PM UTC Severity: 3 - Normal

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

Follow-up Comment #1, bug #60799 (project make): [comment #0 original submission:] > Parser chokes on second expansion of a prerequisite with ; o # > > $ cat makefile > MAKEFLAGS+=--warn-undefined-variables > .SECONDEXPANSION: > hello: $$(shell echo world;) > touch $@ > > bye: $$(hello

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

Follow-up Comment #3, bug #60799 (project make): Yes, it is possible to store special characters in a variable. i'd not bother fixing this, if not for the fact that make already supports this input. It is just when second expansion is enabled the parser fails. i don't think this inconsistency ca

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

Follow-up Comment #1, bug #60811 (project make): $<, $@, etc are the portable automatic variables. These are standardized by posix and supported by other unix makes, e.g. sun and ibm makes. On the other hand, .IMPSRC, etc are not portable. Introduction of .IMPSRC to gmake cannot improve portabilit

[bug #60841] misleading statement in the manual

URL: Summary: misleading statement in the manual Project: make Submitted by: dgoncharov Submitted on: Sun 27 Jun 2021 09:57:28 PM UTC Severity: 3 - Normal Item Group: Do

[bug #60841] misleading statement in the manual

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

[bug #60904] More accurate description of intermediate files

URL: Summary: More accurate description of intermediate files Project: make Submitted by: dgoncharov Submitted on: Sat 10 Jul 2021 02:53:15 PM UTC Severity: 3 - Normal I

[bug #60904] More accurate description of intermediate files

Additional Item Attachment, bug #60904 (project make): File name: sv_60904_doc_clarify_intermediate.diff Size:1 KB ___ 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, &fl); After fcntl return make prints its output. In your case another process has /dev/null locked. With make's s

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

[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 #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 stu

[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

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_fix2.diff Size:6 KB ___ Reply to this item at:

[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

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

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

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

[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 #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 Gro

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

[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: Documentati

[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 #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 #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 #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 shou

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

[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

[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 #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 oth

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

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

[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 #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 #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 #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 indicati

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

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

[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 #52115

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

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

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 rule

[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 https://savannah.gnu.or

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

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

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

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

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

[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 #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 ena

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 case

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

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

[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 %.tsk:

[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 #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 'h

[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: sv48643_preserve_target_specific_vars_o

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 don

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 CFLA

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} ${M:wo

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: .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. Mul

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

[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

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 1

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

[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

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

Follow-up Comment #10, bug #61226 (project make): [comment #9 comment #9:] > I will leave this issue open to think about how to best introduce a backward-incompatible change that might help in this situation. Do i understand it correctly, that as long as compatibility allows, you'd like make to f

[bug #61864] incorrect debug output

URL: Summary: incorrect debug output Project: make Submitted by: dgoncharov Submitted on: Thu 20 Jan 2022 02:30:58 AM UTC Severity: 3 - Normal Item Group: Bug

[bug #61864] incorrect debug output

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

<    1   2   3   4   5   6   7   >