armv7l: 2 Tests in 2 Categories Failed

I wrote: : make-4.4.1.tar.gz : : Linux lime2 5.15.93-sunxi #23.02.2 SMP Fri Feb 17 23:49:46 UTC 2023 armv7l GNU/Linux : : 2 Tests in 2 Categories Failed (See .diff* files in work dir for details) :-( Same problem on Linux raspberrypi 6.1.0-rpi8-rpi-v6 #1 Raspbian 1:6.1.73-1+rpt1 (2024-01-25) ar

undocumented variable MAKE_COMMAND

I got some strange make errors about resetting jobserver mode etc. Long story short, after some debugging I found the reason: I use an optional wrapper for make which I invoke via an environment variable which I (plausbly) named MAKE_COMMAND. To my surprise, I found that recursive makes using $(M

armv7l: 2 Tests in 2 Categories Failed

make-4.4.1.tar.gz Linux lime2 5.15.93-sunxi #23.02.2 SMP Fri Feb 17 23:49:46 UTC 2023 armv7l GNU/Linux 2 Tests in 2 Categories Failed (See .diff* files in work dir for details) :-( makeerror-4.4.1-armv7l-unknown-linux-gnueabihf-bxur.tar.gz Description: application/gzip

Pattern rules without recipe

Another thing that surprised me which I assume is working as designed, but I think should be spelled out clearer in the manual: % cat Makefile MAKEFLAGS += --no-builtin-rules .PHONY: %.a %.b %.c %.a: ; @echo $@ %.b: %.a; @echo $@ %.c: %.a % make x.b x.a x.b % make x.c make: *** No rule to make t

Re: Order-only prerequisites

Henrik Carlqvist wrote: > On Wed, 07 Jun 2023 08:29:15 +0200 > > As I said, a way to specify in which order recipes are invoked > > (here, a before b) if they are invoked, without influencing whether > > they are invoked (only a, only b or a and b, as given on the command > > line). > > So you re

Re: Order-only prerequisites

Henrik Carlqvist wrote: > > Consider this makefile: > > > > .PHONY: a b > > a:; @echo a > > b:; @echo b > > b: | a > > Your problem with this Makefile is that it never creates any files a or b. That's why I made them phony. But that was just for demonstration. I get the same effects with this m

Order-only prerequisites

GNU Make 4.4.1 Consider this makefile: .PHONY: a b a:; @echo a b:; @echo b b: | a What I want to achieve is that a and b can be made independently, but when both of them are made, a is always made first. I assumed that's what order-only prerequisites are for, but they don't seem to work like thi

Pattern rules and '/'

GNU Make 4.4.1 According to the manual, in pattern rules, "the '%' matches any nonempty substring". Accordingly, I'd have expected this Makefile: all: foo-bar/baz foo-%:; echo "$*" to echo "bar/baz". But instead, I get: make: *** No rule to make target 'foo-bar/baz', needed by 'all'. Sto

$(wildcard ...*/) and symlinks

GNU Make 4.4.0.91 Run from an otherwise empty directory: % cat Makefile all: prepare echo $(wildcard */) echo $(wildcard l*/) echo $(wildcard */*/) prepare: mkdir -p d/d touch f d/f ln -sf f l ln -sf f d/l % make -s d/ l d/d/ d/l % So "*/"

Re: Misleading "--debug=w" output for phony target

Paul Smith wrote: > On Wed, 2023-01-18 at 14:45 +0100, Frank Heckenbach wrote: > > % cat Makefile > > .PHONY: a > > a: b; : > > % touch b; touch a; make --debug=w > > Makefile:2: update target 'a' due to: b > > : > > > > Of co

Misleading "--debug=w" output for phony target

% cat Makefile .PHONY: a a: b; : % touch b; touch a; make --debug=w Makefile:2: update target 'a' due to: b : Of course, make should remake a, but not due to b but because it's phony.

Re: duplicate dependencies (with .WAIT)

Paul Smith wrote: > On Tue, 2022-11-01 at 14:15 +0100, Frank Heckenbach wrote: > > So "pause" is run only once. Now, I suppose that's as it's supposed > > to be (by comparison with the same rule without ".WAIT"), and I > > don't expect you t

duplicate dependencies (with .WAIT)

When introducing the new .WAIT special target in some of my makefiles, I noticed a surprising (to me) behaviour, as shown in this example using a simple ad-hoc single-stepping mechanism (not quite my actual use case, but sufficient for this example): % cat Makefile all: step1 .WAIT pause .WAIT ste

Re: GNU Make 4.3.92 release candidate available

Paul Smith wrote: > I expect this to be the final release candidate before GNU Make 4.4. > I will probably allow for testing for about a week. All problems I reported appear fixed, thanks.

[bug #63157] Unlink temporary files.

Follow-up Comment #24, bug #63157 (project make): [comment #23 comment #23:] > Frank wrote [ > > I now found a way to reproduce it quite easily on my system. > As I suspected, it seems to be SIGPIPE: > > % rm -f /tmp/G* > % cat Makefile > all: ; sleep 1 > % make -j2 -O 2>&1 | : > % ls -l /tmp/G

Re: [bug #63157] Unlink temporary files.

Paul D. Smith wrote: > Follow-up Comment #21, bug #63157 (project make): > > The only places leftover files may happen is (a) on Windows, only when (b) you > kill GNU make with ^C or similar. > > Any other leftover files should not happen. Please provide details of the > names of the files that

Re: features/temp_stdin FAILED (was: GNU make 4.3.91 release candidate available)

Dmitry Goncharov wrote: > On Wed, Oct 19, 2022 at 2:33 AM Frank Heckenbach > wrote: > > features/temp_stdin . FAILED (6/7 > > passed) > > [...] > > % cat tests/work/features/temp_stdin.diff.5 > > *** work/features/temp_

features/temp_stdin FAILED (was: GNU make 4.3.91 release candidate available)

% uname -a Linux mars 5.10.0-19-amd64 #1 SMP Debian 5.10.149-1 (2022-10-17) x86_64 GNU/Linux % tar xf make-4.3.91.tar.lz % cd make-4.3.91 % ./configure --prefix=/usr % make -j % make check [...] features/temp_stdin . FAILED (6/7 passed) [...] % cat tests/work/fe

[bug #63157] Unlink temporary files.

Follow-up Comment #20, bug #63157 (project make): Unfortunately, I still get leftover temp files and fifos with 4.3.91. If I understand you right, it's not worth investigating it further now, is it? Just one guess: Since I pipe make's output to my tools, that might be the cause. So you might wan

Re: GNU make 4.3.91 release candidate available

> * WARNING: Future backward-incompatibility! > In the NEXT release of GNU Make, pattern rules will implement the same > behavior change for multiple targets as explicit grouped targets, below: if > any target of the rule is needed by the build, the recipe will be invoked if > any target of

[bug #63157] Unlink temporary files.

Follow-up Comment #18, bug #63157 (project make): [comment #17 comment #17:] > Paul, if you decide to proceed with changes in comment 11, temp_stdin_fileno should probably be of type volatile sig_atomic_t, rather than int. Are you sure that's big enough? According to https://cplusplus.com/refere

[bug #63157] Unlink temporary files.

Follow-up Comment #15, bug #63157 (project make): FWIW, I do consider this a regression, since these things weren't even created before. Now, after some weeks of trying make 4.3.90, I get a number of empty files and named pipes lying around -- probably from aborted make runs, but such is life (so

Re: GNU make 4.3.90 release candidate available

> * Some POSIX systems (*BSD) do not allow locks to be taken on pipes, which > caused the output sync feature to not work properly there. Also multiple > invocations of make redirecting to the same output file (e.g., /dev/null) > would cause hangs. Instead of locking stdout (which does have

Re: GNU make 4.3.90 release candidate available

I noticed a change in behaviour which I didn't find mentioned in (or an apparent consequence of) the listed backward-incompatible changes. I have a pattern rule like "%.c %.h &: %.y" for a tool (Bison) that may generate two output files (.c and .h), but in some cases (depending on the option "--de

Re: [SCM] make branch, master, updated. 4.3-234-gf6ea899d

> [SV 13862] Implement the .WAIT special target > > The next version of the POSIX standard defines parallel execution > and requires the .WAIT special target as is implemented in some other > versions of make. > > * doc/make.texi (Parallel Disable): A new section to di

Feature request: -j100%

GNU parallel has a "-j" option quite like GNU make. But it also allows to specify the number of jobs relative to the number of CPU cores present: --jobs N -j N Number of jobslots on each machine. Run up to N jobs in parallel. 0 means as many as possible. Default is 100% which

Re: Keeping intermediate files

Jeffrey Walton wrote: > Related, you usually ask the compiler to save the intermediate files. > For GCC the option is -save-temps. Also see > https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html. Indeed, as far as compiler-intermediates are concerned. I know this option and it works well. Her

Keeping intermediate files

Is there are way to completely stop GNU make from removing intermediate files? When something goes wrong, I sometimes like to examine things step by step, and intermediate files are sometimes useful in that. I fail to see any benefit in removing them -- it's certainly not that they blow up generat

Re: Manual: Multiple outputs

I had accidentally posted to bug-make@gnu.org first, but this belongs to bug-autom...@gnu.org. Paul Smith wrote: > On Mon, 2021-05-03 at 12:55 +0200, Frank Heckenbach wrote: > > The manual ( > > https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html > &

Manual: Multiple outputs

The manual (https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html) describes various ways to handle commands with multiple outputs. One intermediate solution that's said to work except with phony dependencies doesn't actually seem to work: % cat Makefile all: data.c data.h

Parallel input synchronization

Hi, as you know, GNU make has added an output-sync option some time ago, but has no mechanism to handle input to parallel jobs. Indeed, this is rarely needed, but I actually have a use case, so I implemented a solution, which does not require any changes to make (unlike output-sync), just changes

[bug #45311] makes only one of two dependencies that depend on the same subdir-pattern rule

Follow-up Comment #4, bug #45311 (project make): $@ wasn't the source of my confusion. Though the simplified test case would indeed have worked if $@ expanded to all targets, my actual Makefile wouldn't. What confused me was the different behaviour of multiple-target rules with and without patter

[bug #45311] makes only one of two dependencies that depend on the same subdir-pattern rule

URL: Summary: makes only one of two dependencies that depend on the same subdir-pattern rule Project: make Submitted by: frank Submitted on: Fr 12 Jun 2015 22:55:52 GMT Severity: 3 - N

[bug #43921] make does not check error result of ttyname()

URL: Summary: make does not check error result of ttyname() Project: make Submitted by: frank Submitted on: Sa 03 Jan 2015 08:39:03 GMT Severity: 3 - Normal Item Group: B

Re: GNU make 4.0.90 prerelease available

Paul Smith wrote: > The first pre-release GNU make 4.0 is available on the alpha FTP site > (or via HTTP): > > 6df6ca5791437cd3212c21872ddc29cb > ftp://alpha.gnu.org/gnu/make/make-4.0.90.tar.gz > 6df10668d06f9a2ef152995bd5b577e4 > ftp://alpha.gnu.org/gnu/make/make-4.0.90.tar.bz2 Looks good a

Re: Bug-fix release of GNU make

Paul Smith wrote: > I'd like to make a bug-fix release of GNU make within the next couple of > weeks, before a new set of potentially disruptive changes go in. There > have been some important fixes since 4.0 was released. > > If you have particular bugs that you'd like to see addressed please >

Re: Phony targets and pattern rules

Paul Smith wrote: > OK I've reworded this. I changed the title of the catalog section to be > "Catalogue of Built-In Rules" instead, and reworded the Phony Targets > section. I think it's clearer now, thanks! Frank ___ Bug-make mailing list Bug-make@

Re: Phony targets and pattern rules

Paul Smith wrote: > On Sat, 2014-09-06 at 20:01 +0200, Frank Heckenbach wrote: > > > Since it knows that phony targets do not name actual files that > > > could be remade from other files, `make' skips the implicit rule > > > search for

Re: Phony targets and pattern rules

Paul Smith wrote: > On Sat, 2014-09-06 at 19:38 +0200, Frank Heckenbach wrote: > > I know that specific rules take precendence over pattern rules (e.g. > > if I had a rule "foobar:;", I wouldn't expect the echo to run), as > > the documentation says: "

Phony targets and pattern rules

Is this the intended behaviour? % cat Makefile .PHONY: all foobar all: foobar foo%:; echo $@ % cat foobar cat: foobar: No such file or directory % make make: Nothing to be done for 'all'. (Wherease when "foobar" is not listed as .PHONY, echo is run.) "make -d" reveals: Considering target file '

New release

Hi Paul, are you planning to make a new release anytime soon? I noticed the version currently in Debian testing still contains some output-sync bugs (e.g. the buggy Makefile "all:; $(foreach" does not produce an error message with "--output-sync", which is fixed in git), so it would be a shame if

[bug #41677] wrong message "did you mean TAB instead of 8 spaces"

URL: Summary: wrong message "did you mean TAB instead of 8 spaces" Project: make Submitted by: frank Submitted on: So 23 Feb 2014 23:15:29 GMT Severity: 3 - Normal Item G

Re: output from $(error) lost with output sync

Paul Smith wrote: > I fixed this one locally a couple of days ago; sorry for not pushing. > I'll do that shortly. > > I don't think this change is sufficient because if output_sync != > &make_sync then make_sync is never dumped with the change below. I had assumed it wasn't a problem because mak

Re: output from $(error) lost with output sync

Oliver Kiddle wrote: > Given the following Makefile, the output from the error function is > being lost when the gmake 4 output-sync is enabled: > > [...] With assertions active I even get this error: % make -O make: main.c:3409: die: Assertion `output_context == &make_sync' failed. Aborted I

Re: [bug #40225] Deterministic output ordering

Paul D. Smith wrote: > I don't think Frank's suggestion below will work (or maybe I misunderstood > it). It's not enough to remember the order in which target recipes were > started, because in parallel builds the order of starting targets can be > different. > > [...] > > What we'd need to do is

[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly

Follow-up Comment #13, bug #40361 (project make): @#12: Yes, exactly. Now we'll have to find out which one of vsnprintf() and va_copy() is broken and how to work around it. Are you familiar with C and can you do some tests to find out? (You can try standalone programs based on these functions, t

[bug #40361] make 4.0 under hpux 11.31 no longer prints output correctly

Follow-up Comment #10, bug #40361 (project make): Another thing that changed in the course of the output patches is that messages are now generated in vfmtconcat() using vsnprintf() as well as va_copy(), both C99 and at least the latter AFAIK not very widely used. For testing you could try replac

Re: [bug #40225] Deterministic output ordering

Tim Murphy wrote: > One problem with reordering is how do you do it without actually > affecting the way you schedule jobs? Dunno, maybe just like I described it in http://lists.gnu.org/archive/html/bug-make/2013-10/msg00065.html > [...] > > So, you might say, it's not random because there are

Re: [bug #40225] Deterministic output ordering

Edward Welbourne wrote: > > Or just use diff? > > That involves having two built directories, one holding the last build's > log files, the other holding the new build's; that may be OK, if you're > keeping all your old build directories (maybe as tar-balls) anyway, for > other reasons, but addin

[bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

Follow-up Comment #15, bug #33034 (project make): David Boyce wrote: > I agree with some of your points but there was a bit of cherrypicking involved in the quoting: > > > ... really, what's the chance a trivial one-line change to the top-level makefile will actually break your driver? > > I'm

Re: [bug #40225] Deterministic output ordering

Edward Welbourne wrote: > Then commit all the log files to git and use git show to find out which > of them have changed since the last build. (I trust you can all work > out the equivalent steps for *your* preferred SCM system.) This only > has to happen on the server that builds from clean on

Re: [bug #40225] Deterministic output ordering

Paul D. Smith wrote: > A non-parallel build is actually fully deterministic for a given makefile. > Make (I believe this is specified by POSIX) will always try to build the first > prerequisite first, then the second, etc. Of course there are ways to get > non-determinism: for example IIRC the $(

[bug #40225] Deterministic output ordering

Follow-up Comment #1, bug #40225 (project make): First, I wonder how deterministic the order in a non-parallel build actually is. I guess, formally it's not, but for practical purposes it is, i.e. given the same make version and the same makefiles, it's unlikely to change. When I had a need like

Re: [bug #33138] .PARLLELSYNC enhancement with patch

I tested the new version and found no new issues, so as far as I'm concerned this feature can now be considered finished. Thanks for the initial patch, David, and the integration into GNU make, Paul! ___ Bug-make mailing list Bug-make@gnu.org https://lis

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Edward Welbourne wrote: > >> All but one of those I've looked into is manifestly less powerful than > >> make (and I'm still waiting for my former colleagues to get the > >> exception released to open source). > > > I have no illusions that there aren't very serious issues with make and > > I hav

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > On Thu, 2013-09-19 at 14:47 +0200, Frank Heckenbach wrote: > > Paul Smith wrote: > > > > > I didn't fix it this way. Instead I used the existing MAKE_RESTART > > > environment variable to communicate from the current make to the >

Re: GNU make 3.99.92 release candidate is available

Try this patch. I don't use EMX myself, but I noticed this when reading through the lastest changes, and it seems to fit your bug description. --- function.c.orig 2013-09-22 07:53:27.0 +0200 +++ function.c 2013-09-24 16:21:37.0 +0200 @@ -1710,7 +1710,7 @@ CLOSE_ON_EXEC(pipe

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > On Thu, 2013-09-19 at 14:47 +0200, Frank Heckenbach wrote: > > > Hm. This is pretty contrived. I have a hard time imagining a real > > > makefile wanting to do this for a good reason. However, it does > > seem > > > that the solution m

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > *sigh* If it weren't for the enter/leave messaging, the output-sync > feature would have been quite straightforward! :-/ :-). I'm afraid so. But I think we're almost there now. > On Mon, 2013-09-16 at 12:18 +0200, Frank Heckenbach wrote: > >

Re: [bug #33138] .PARLLELSYNC enhancement with patch

(I'm afraid I hadn't seen your message from Sep 12, only your followup on Sep 14, so I'm a bit late ...) Paul Smith wrote: > > One of the issues you were running into with your makefile is that > > output from functions like $(info ...) that were expanded inside the > > recipe were simply being p

[bug #39943] Add an alternative parsing mode that regards space and tab

Just my 2¢ ... Paul D. Smith wrote: > As for your suggestion regarding the term "hard tab", when I wrote that > message I'd never heard this term. I'm still not sure why the prefix "hard" > is added; what is being distinguished by this? A TAB is a TAB, and there's > only one TAB character. The

Re: [bug #33138] .PARLLELSYNC enhancement with patch

May I remind you of my mail of May 26: http://lists.gnu.org/archive/html/bug-make/2013-05/msg00137.html Besides a little cleanup patch, I show in this mail that "--trace=dir" is not completely sufficient as currently implemented (including test case). I realize that you don't like the full tracin

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Eli Zaretskii wrote: > > From: Frank Heckenbach > > > > > > void write (int fd, void *data, size_t size) > > > > { > > > > if (getflags (fd) & O_APPEND) > > > > { > > > > lock_mutex (get_mutex (fd)); &g

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Eli Zaretskii wrote: > > From: Frank Heckenbach > > > > Eli Zaretskii wrote: > > > > > The problem exists, but there's nothing that can be done about it, as > > > long as we use write/fwrite/fprintf for this: the call to 'write' > &

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Martin Dorey wrote: > > That said, I'm now going back to my own programs which redirect > > stdout in forked child processes and add O_APPEND to O_TRUNC ... > > Me too! I just realized that this also applies to the temp files created for output-sync, since tmpfile() doesn't set O_APPEND. The pro

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Eli Zaretskii wrote: > > From: Frank Heckenbach > > > > However, there may still be a problem. The trick about O_APPEND on > > POSIX it that it's atomic, i.e. nothing can get between moving the > > file pointer and the write, even if another process tries to

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Eli Zaretskii wrote: > > If Windows has a function to make a copy of a FD, whatever it is, > > with new flags, this plus dup2 would be mostly equivalent to fcntl > > for our purposes indeed. > > On Windows, file descriptors are created and maintained by the C > runtime, and they are private to th

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Martin Dorey wrote: > Frank wrote: > > > the two-step procedure (remove and ">>"). > > Woah, *truncate* and ">>". Removal wouldn't do the right thing for symlinks. You're right, of course, thanks! > > That said, I'm now going back to my own programs which redirect > > stdout in forked child p

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Eli Zaretskii wrote: > > Date: Mon, 27 May 2013 00:42:34 +0200 > > From: Frank Heckenbach > > Cc: bug-make@gnu.org > > > > One issue, though it might seem strange that I'm the one to mention > > it, is that it might be POSIX specific. How do other syst

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

Paul Smith wrote: > Nevertheless, I do wonder whether forcing stdout/stderr into O_APPEND > mode would be worthwhile. It would fix this problem in any event. I'm > having a hard time coming up with a reason NOT to do it. One issue, though it might seem strange that I'm the one to mention it, is

Re: Make run in parallel mode with output redirected to a regular file can randomly drop output lines

(Sorry, I can't reply properly; I'm not subscribed, just saw the message on the web archive.) Stefano Lattarini wrote: > Make run in parallel mode with output redirected to a regular file > can randomly drop output lines Yet another reason to use the new --output-sync feature. :) I hadn't actua

Re: [bug #33138] .PARLLELSYNC enhancement with patch

I've tested the current output-sync implementation in my use case, using "--output-sync=line --trace=dir". I definitely need "--trace=dir" since I want to refer my compiler errors automatically to their directories. Without this option, this often goes wrong in parallel builds. (Which just means,

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > The first one I've seen but hadn't had time to debug. I'll look at your > patch. I left the truncate where it was rather than doing it after the > sync_output() because I was hoping to avoid truncating a file that we'll > never use again anyway, but I guess it isn't a big dea

Re: [bug #33138] .PARLLELSYNC enhancement with patch

: I've tested your changes and so far "-O job" works for my use cases. I shouldn't have written that. :-( Shortly afterwards, I found a bug or perhaps two: foo: @echo foo +@echo bar (a) % make -Ojob foo bar foo (b) % make -Otarget bar foo As you see, (a) "-Ojob" writes "foo" tw

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > I went a different way: I modified the child_error() function so that if > there was an output-sync file, the error message would be written to the > end of that file instead of printed directly. This way when the output > is shown to the user she sees the entire thing, includ

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Sun, 28 Apr 2013 22:03:39 -0400 > > > > Now that we seem to have a workable solution for output synchronization > > for both POSIX and Windows systems, I wonder if we shouldn't consider > > enabling it as the default mo

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > On Sun, 2013-04-28 at 20:00 +0300, Eli Zaretskii wrote: > > > I've pushed a change to add a new argument to the -O/--output-sync > > > option, "job", to write output after each line of the recipe. > > > > What is its purpose? To avoid mixing in the same screen line > > charac

Re: [bug #33138] .PARLLELSYNC enhancement with patch

David Boyce wrote: > On Sun, Apr 28, 2013 at 1:34 AM, Paul Smith wrote: > > I'm not excited about that term ("job"); it's kind of accurate, but in > > the documentation for example we're really mushy about exactly what a > > "job" is, vs. a "recipe" or a "command line" etc. I'd like to pick some

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > You underestimate me ;-) > > What I have is actually this: > [...] > > and I wrote 'fcntl' emulation for Windows that uses a mutex. Indeed, I had not expected this. :-) > That said, I'm not wedded to the above approach, and if people like a > completely disjoint code for

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > > Date: Thu, 25 Apr 2013 02:16:33 +0200 > > Cc: e...@gnu.org, bug-make@gnu.org > > From: Frank Heckenbach > > > > > > I can't follow you here. On POSIX, we don't need to pass a fd > > > > because it's always

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > > From: Paul Smith > > Cc: Frank Heckenbach , bug-make@gnu.org > > Date: Wed, 24 Apr 2013 16:03:56 -0400 > > > > > Or maybe we should abandon this optimization and take the lock > > > regardless. How bad can that be? > >

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > On Wed, 2013-04-24 at 20:46 +0200, Frank Heckenbach wrote: > > That's true about SEEK_CUR which was there originally. I actually > > changed it to SEEK_END, which does move the position to the end. > > Oh right. My head cold is keeping me fogg

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > > : Btw, there will be other side effects, at least on non-Posix > > : platforms, due to the fact that stuff that was supposed to go to the > > : screen is redirected to a file instead. Some programs sense that and > > : behave differently, e.g. with binary non-printable ch

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > > I know about this method, but I'm not sure it does what we want here. > > The number used by this method is not guaranteed to be unique on some > > versions of Windows. More importantly, it only works for disk files, > > I don't know whether it reports a meaningful value

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > That's one way. Another one is to discuss the design more thoroughly > before the patches are accepted. I think it was discussed quite extensively. Also in retrospect, I don't see how the design could have been much different (see below). > I tried to turn the discussion

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > > Date: Tue, 23 Apr 2013 21:41:22 +0200 > > From: Frank Heckenbach > > > > Sure, it's excluding much more than necessary, but since > > the critical section is very short, this shouldn't hurt much. (In > > other words, if make

Re: [bug #33138] .PARLLELSYNC enhancement with patch

David Boyce wrote: > The first thing is get the word "lock" out of your mind because we aren't > really locking anything. Yes, that API is in use but it's only to create a > semaphore or baton. Nobody is ever prevented from doing anything. It just > happens that on Unix the most portable (i.e. old

Re: [bug #33138] .PARLLELSYNC enhancement with patch

(TL;DR: Probably irrelevant.) Paul Smith wrote: > I'm not sure if the lock locks the FD (so that if you dup'd the FD but > it still pointed to the same output, you could take exclusive locks on > both), or if it locks the underlying resource. If the former I guess > it's possible to break the sy

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > Initial investigation indicates that tmpfile should do the job just > fine: the file is deleted only when the last descriptor for it is > closed. That includes any duplicated descriptors. Great. > As for fcntl, F_SETLKW, and F_GETFD, they will need to be emulated. > In pa

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote: > > And with my progress mechanism, that's exactly what I want. In my > > case it'd look like this: > > > > [Start] Compiling foo.c > > [Start] Compiling bar.c > > # ti

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Eli Zaretskii wrote: > > Date: Thu, 18 Apr 2013 20:39:44 +0200 > > Cc: psm...@gnu.org, e...@gnu.org, bo...@kolpackov.net > > From: Frank Heckenbach > > > > Indeed, as you suggested earlier, it might be useful to use the main > > part of open_tmpfile() (i.e

Re: [bug #33138] .PARLLELSYNC enhancement with patch

David Boyce wrote: > On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach > wrote: > > > FILE is an opaque structure which should never be allocated by user > > code, so its layout can be implementation specific. > > Of course it's an opaque structure. The pr

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > On Thu, 2013-04-18 at 19:09 +0200, Frank Heckenbach wrote: > > This mechanism was unaffected by my output-sync patch, and I > > expected your change broke it. > > I was reading your email with interest, waiting for the punch-line, but > then after

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Paul Smith wrote: > I've applied the patch from Frank. Thanks. I did some tests and so far everything works in my setup. Since I was away for a day, I couldn't follow the discussion earlier, so allow me to respond to several mails at once ... > I changed the behavior so that the entire recipe >

[bug #33138] .PARLLELSYNC enhancement with patch

Follow-up Comment #11, bug #33138 (project make): By a strange coincidence I just found a bug today: pump_from_tmp_fd() would only copy one buffer (8k) full of data, because the check "nleft <= 0" was after the loop which decremented nleft to 0 while writing. Moving it before the loop fixes the b

[bug #33138] .PARLLELSYNC enhancement with patch

Follow-up Comment #10, bug #33138 (project make): Thanks. If you have any questions, let me know. I'm attaching a version of the patch which is unchanged except for adding the usage line for --parallel-sync. (file #27793) ___ Additional It

[bug #38051] "-n" option gets lost when included Makefile is remade in recursive job

URL: Summary: "-n" option gets lost when included Makefile is remade in recursive job Project: make Submitted by: frank Submitted on: Do 10 Jan 2013 03:09:25 GMT Severity: 3 - Normal

[bug #33138] .PARLLELSYNC enhancement with patch

Follow-up Comment #6, bug #33138 (project make): PS: Ignore the ugly line breaks in the mail. I posted the comment via Savannah (where the lines appear correctly). Apparently it messed them up when forwarding it via email. :-( ___ Reply to

[bug #33138] .PARLLELSYNC enhancement with patch

Follow-up Comment #5, bug #33138 (project make): David Boyce wrote: > This is the original author. I've become very busy at my day job in the last > year or two so I've lost track of this. Thanks for picking it up and improving > it. I haven't had time to look at your new patch yet, and not sure

[bug #33138] .PARLLELSYNC enhancement with patch

Follow-up Comment #3, bug #33138 (project make): The current patch doesn't work well with recursive makes. The test case (sync-recursive-demo.tar.gz) demonstrates this. Its output with "make -j" is the following: make -C foo make -C bar [2s delay] make[1]: Entering directory 'foo' foo: start foo:

  1   2   >