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)
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
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
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
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
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
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
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'.
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
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 course, make
% 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.
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 to change anythi
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
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.
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
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
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_
% 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
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
> * 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
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
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
> * 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
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
> [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
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
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.
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
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
> &
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
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
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
URL:
http://savannah.gnu.org/bugs/?45311
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 -
URL:
http://savannah.gnu.org/bugs/?43921
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:
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
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
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
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
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: The rules you write take precedence over
those
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 phony targets (*note Implicit Rules
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
URL:
http://savannah.gnu.org/bugs/?41677
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
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
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
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
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 not
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 adding the
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
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
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 may be simple enough.
I also doubt someone
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:
1.
Twice Entering, once
Eli Zaretskii wrote:
From: Frank Heckenbach f.heckenb...@fh-soft.de
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'
isn't atomic on Windows even without O_APPEND
Eli Zaretskii wrote:
From: Frank Heckenbach f.heckenb...@fh-soft.de
void write (int fd, void *data, size_t size)
{
if (getflags (fd) O_APPEND)
{
lock_mutex (get_mutex (fd));
off_t pos = get_size (fd);
do_write (fd, pos, data, size
Eli Zaretskii wrote:
Date: Mon, 27 May 2013 00:42:34 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
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 systems behave,
can they set
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 processes and add
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 the
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
: 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 twice
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 deal.
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
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
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 for the
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
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 foggy. What was the reason to
change
Eli Zaretskii wrote:
From: Paul Smith p...@mad-scientist.net
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, 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?
Well, we want
Eli Zaretskii wrote:
Date: Thu, 25 Apr 2013 02:16:33 +0200
Cc: e...@gnu.org, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
I can't follow you here. On POSIX, we don't need to pass a fd
because it's always stdout/stderr. Or do mean something else?
I meant
(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
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. oldest)
Eli Zaretskii wrote:
Date: Tue, 23 Apr 2013 21:41:22 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
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 jobs produce such huge output
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
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
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 all that description you just said
David Boyce wrote:
On Thu, Apr 18, 2013 at 10:09 AM, Frank Heckenbach
f.heckenb...@fh-soft.dewrote:
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 problem
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 f.heckenb...@fh-soft.de
Indeed, as you suggested earlier, it might be useful to use the main
part of open_tmpfile() (i.e. without the fdopen
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
# time passes
foo.c: some error
# time passes
bar.c: some
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
URL:
http://savannah.gnu.org/bugs/?38051
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
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
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
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:
BTW, I wanted to check against the current repository version, but
when I tried to fetch it as described on
https://savannah.gnu.org/git/?group=make, I got:
% git clone git://git.savannah.gnu.org/make.git
Cloning into make...
warning: You appear to have cloned an empty repository.
Using the attached Makefile, I get the following result:
% rm -f foo; make -j
foo1
bar1
qux
start foo
bar
foo
So the qux recipe is run before foo is finished (or even started),
although qux depends on foo. The $(shell) calls as well as
.SECONDARY and the seemingly unrelated bar rules all seem to
Follow-up Comment #2, bug #33138 (project make):
Some remarks on the current patch:
assign_child_tempfiles():
+ /* Check status of stdout and stderr before hooking up temp files. */
+ o_ok = STREAM_OK(stdout);
+ e_ok = STREAM_OK(stderr);
Why do you check these for each recipe and not just
83 matches
Mail list logo
