[bug #61957] Document the side effect of mentioning a file explicitly.

URL: Summary: Document the side effect of mentioning a file explicitly. Project: make Submitted by: dgoncharov Submitted on: Sat 29 Jan 2022 01:32:57 AM UTC Severity: 3 - Normal

[bug #61955] Remade Makefiles & Phony Targets

Follow-up Comment #2, bug #61955 (project make): > I see that this is not documented in the manual so that should be fixed; > I will convert this into a documentation bug. Еhere is https://savannah.gnu.org/bugs/?61623 with a patch that documents phony makefile targets.

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

Follow-up Comment #37, bug #48643 (project make): > The first one is that the output appears even if make ultimately decides that there is no way to build the target. i think, this is good. Hopefully, this will prevent users from writing makefiles that depend on compat search. > When I put my

Re: $(info xxx) output interleaved with other $(info) output

On Thu, Jan 20, 2022 at 5:41 PM Paul Eggert wrote: > I suggested working around the problem in the GNU Emacs Makefiles by > installing the attached patch. It's a bit of a hack but I couldn't think > of anything better, other than outputting the information with the shell > rather than with

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

Follow-up Comment #35, bug #48643 (project make): > Do you mean that if I apply the test patch mentioned there, some of those tests would fail? All tests should pass. in the case of example 6 make fails to set pat->is_explicit for 'hello.x'. This used to fail example 6 until commit 6682fb. My

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

Follow-up Comment #33, bug #48643 (project make): This fix turned out to be difficult. i'll be surprised if we don't miss anything. i wanted to bring to your attention a couple of leftovers. One is that pat->is_explicit that is described in update 31. For the other let's consider example 8.

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

Follow-up Comment #31, bug #48643 (project make): Paul, in update 27 i added 2 patches. sv48643_exp_preqreq_is_not_interm.diff has a fix for example 6. sv48643_exp_preqreq_is_not_interm_tests.diff has related tests. Not sure, if you decided not to apply these 2 patches or they fell through the

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

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

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

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.

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

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}

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

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.

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

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

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.

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

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.

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

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 #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_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

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

On Monday, October 25, 2021, Alejandro Colomar (man-pages) < alx.manpa...@gmail.com> wrote: > However, there's a downside to this: The payment for this robustness is a > non-negligible time cost. The single-process time for a no-op make is > around 10 s > > 10s is about 100 to 1000 times

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

On Monday, October 25, 2021, Alejandro Colomar (man-pages) < alx.manpa...@gmail.com> wrote: > > > Why do I do this? Because, if you remove a file from your tree, an old .d > file will require that file and make your build fail, requiring you to > clean before making again. > > This has been

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

On Sun, Oct 17, 2021 at 11:17 PM Britton Kerin wrote: > I got that but it sounds like the proposal is for it to do one thing > if the file is a .d and otherwise something else? The proposal is to see if the recipe is empty. There is this statement in the manual "If a rule has no prerequisites

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

On Mon, Oct 25, 2021 at 6:12 AM Edward Welbourne wrote: > Surely that would solve your problem, without invasive surgery in GNU > make, or special-case handling of .d files anywhere but your make file ? Actually, my makefiles do not suffer from this. i use the technique described here

Re: -V, --verbose, as opposite of -s, --silent, --quiet

On Fri, Oct 22, 2021 at 9:02 PM Alejandro Colomar (man-pages) wrote: > The output would be something like: > > CC foo.o > CC bar.o > ... > > But then, if something goes wrong (e.g., bar.c stops compiling into > bar.o), I'd like to be able to debug the build by showing the full command.

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

On Sun, Oct 17, 2021 at 3:05 PM Britton Kerin wrote: > If I understand right that the idea is a special case for .d files The question being discussed is what to do when make cannot include a makefile. regards, Dmitry

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

Re: Make language

On Tue, Oct 12, 2021 at 10:38 AM Bartol Hrg wrote: > > Greetings > > I installed make 3.81 for Windows > > It's in d*mn Croatian! > > Now, I don't know if you noticed, but I speak English. > > I'm really displeased and agitated. > > Best regards > B. Helium Dobar dan. Vaš pošta je na Engleskom

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

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.

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.

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.

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.

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

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.

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.

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 #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 #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 #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_reuse_rule_name_for_dash_p.diff Size:0 KB ___ Reply to this item

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

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

On Sun, Jul 25, 2021 at 3:25 PM Paul Smith wrote: > I have no problem with make refusing to write to a device that's locked > in general. If users don't want that to happen, they can just not use > the -O option. True, as long as the user knows that when -O is specified make is going to lock

[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: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sun, Jul 25, 2021 at 10:03 AM Paul Smith wrote: > Writing to > things like /dev/lp0 SHOULD be locked, IMO: you don't want multiple > concurrent writers to your printers or your terminal! The user intentionally redirects make to a printer along with another tool. Should make be smarter than

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

On Sun, Jul 25, 2021 at 3:49 AM Eli Zaretskii wrote: > > Follow-up Comment #8, bug #60774 (project make): > > Why did you remove the code which reused the mutex passed from the parent > Make? Eli, i don't think i removed any code, other than the global variable mutex_handle. Atleast, not

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

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

Wanted to test that windows this still works with this change. So, i followed instructions in README.W32. Installed mingw gcc. Copied config.h.W32.template to config.h.w32. Ran build_W32.bat gcc. It fails with C:\dgoncharov\make>gcc -mthreads -Wall -std=gnu99 -gdwarf-2 -g3 -O2 -DMAKE_MAINT

[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

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

On Sat, Jul 24, 2021 at 3:02 PM David Boyce wrote: > The point is that only /dev/null *should* be shared. Any other file *might* > be locked by an unrelated process but that would represent an error condition > in which incorrect results should be expected. i think, it is less likely that an

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

On Saturday, July 24, 2021, David Boyce wrote: > Wouldn’t a less intrusive solution be to check the inode/device of stdout > and if it’s the same as that of /dev/null just forego locking? That would help this specific case indeed. What about a case when make's stdout is redirected to another,

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

On Saturday, July 24, 2021, Eli Zaretskii wrote: > Follow-up Comment #5, bug #60774 (project make): > > The MS-Windows port of GNU Make doesn't lock stdout (or any other standard > device). Instead, it uses a mutex to synchronize output. So I think this > problem cannot happen on Windows.

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

Re: [bug #60841] misleading statement in the manual

On Mon, Jun 28, 2021 at 10:23 AM Andreas Schwab wrote: > > "When make runs a recipe, variables defined in the makefile are placed into > > the environment of each shell." > > Please also read the rest of the paragraph. This statement should say "variables defined in the makefile can be

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

[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

Re: [bug #60798] Make does not compile with GCC 11.1.0

On Sat, Jun 19, 2021 at 10:31 AM Dmitrii Pasechnik wrote: > It's undefined behaviour in C to point to such a location, isn't it? > Is this hack really needed? There is no hack. It is pointer arithmetic in c. p[-1] is the same as *(p-1). regards, Dmitry

[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

<    1   2   3   4   5   6   7   >