On Thu, 2021-12-23 at 12:49 +, Zhu, Mason wrote:
> In GNU Make 3.82, it seems that -j option will be finally added if
> Make determines my VM has the parallel build capability.
It has never been the case that any version of GNU make has
automatically enabled parallel builds by itself. It's al
On Fri, 2021-12-24 at 10:45 +, Humm wrote:
> Consider the Makefile:
>
> .POSIX:
> M = word
> all:
> echo ${M:word=a\
> b}
>
> I believe, as the escaped newline is in a command line, the expected
> behavior is to let the macro expand to i
On Fri, 2021-12-24 at 23:30 +, Humm wrote:
> (woops, sorry for replying off-list first; mutt doesn’t like me)
>
> Quoth Paul Smith:
> > In your example the backslash is part of a variable expansion: it's
> > INSIDE the variable expansion so it will be handled by mak
While looking through some old bugs in Savannah and trying to reproduce
them I ran across this change in behavior between GNU make 4.3 and
current Git master HEAD:
$ cat Makefile
1.all: 1.q ; touch $@
%.q: 1.r ; touch $@
%.r: ; touch $@
Note here, 1.r is mentioned explicitly in the makefi
On Wed, 2021-12-29 at 18:04 -0500, Paul Smith wrote:
> This is just not a good idea anyway, and now that we have the
> is_explicit value in the file structure we don't need it so I removed
> that code. Unfortunately is_explicit is not correctly preserved in
> pattern_search(
On Fri, 2022-01-07 at 18:28 -0500, Joe Filion wrote:
> Line 3094 of read.c is:
>
> char *userend = strchr (name + 1, '/');
>
> The name parameter is a const pointer, so the overloaded version of
> strchr that takes a const pointer as the first parameter should also
> return a const pointer.
Yo
On Sat, 2022-01-08 at 19:47 +0100, Henrik Carlqvist wrote:
> On Sat, 08 Jan 2022 10:37:17 -0500
> Paul Smith wrote:
> > The const-correct way to write this code would be to allocate a new
> > string and modify that
>
> Another correct way to do this would be to not decl
On Sat, 2022-01-08 at 21:37 +0100, Alejandro Colomar (man-pages) wrote:
> Hi Dmitry,
> On 1/7/22 17:48, Dmitry Goncharov wrote:
> > 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
On Sat, 2022-01-08 at 22:34 +0100, Henrik Carlqvist wrote:
> But what about the case marked with <--X above? To me it seems as if
> the function returns after having modified const char *name bu using
> userend.
You're right, that's wrong.
It turns out to be innocuous because none of the callers
On Sun, 2022-01-09 at 11:06 +0100, Henrik Carlqvist wrote:
> On Sat, 08 Jan 2022 17:29:33 -0500 Paul Smith wrote:
> > It turns out to be innocuous because none of the callers care that
> > the value of the input string is modified if we return a different
> > string, but
On Tue, 2022-01-11 at 10:57 +, Edward Welbourne wrote:
> Indeed. The compiler is allowed to place a string literal in read-
> only memory, where modifying it (even if you do "put it back the way
> it was" later) is an access violation. Passing such a const char *
> to your function would thus
On Wed, 2022-01-12 at 14:22 -0900, Britton Kerin wrote:
> > You can see that this example mimics your .silent example.
> > Your makefile provided a prerequisite to .SILENT. Make then knows
> > that .SILENT has a prerequisite.
>
> I agree that it's consistent syntax, but semantically it's bad. Th
On Sun, 2022-01-09 at 20:02 -0500, Joe Filion wrote:
> If interested, I found another similar construct in another area of
> the code. Don’t worry, this appears to be the last one.
>
> On line 557 of implicit.c:
> p = strchr (nptr, '%');
> nptr is a const pointer, but p is used
On Thu, 2022-01-13 at 23:31 +0100, Jouke Witteveen wrote:
> I would like to draw attention to this patch again, since without
> it the intcmp function is misbehaving.
Thanks for reminding me: somehow the original got deleted from my inbox
without being applied. I've now applied it to my Git repo
On Sat, 2022-01-15 at 10:29 +, Sven C. Dack wrote:
> I have recently been looking into this again, because of a new
> feature I am currently testing, and so far can only repeat what I
> have already said in the past. The /proc/loadavg file under Linux
> with a vanilla kernel is behaving as expe
On Tue, 2022-01-18 at 10:56 -0500, Joe Filion wrote:
> I could recommend changing line 557 to something like:
>
> const char * cp = strchr (nptr, ‘%’);
Good idea, thanks. I cleaned up this section of code.
hanged.
I examined this method and in fact, it's not possible for it to be
called with anything other than exactly one argument so all the mess
around recombining multiple arguments is useless.
I rewrote this function and applied this change:
Author: Paul Smith
Date: 2022-01-19 15:49:19
On Sat, 2022-01-22 at 13:59 +0100, Gisle Vanem wrote:
>define add_c_src>
> VPATH += $(1)
> C_SRC += $(addprefix $(1)/, $(2))
> $(info Number of 'C_SRC': $(words $(C_SRC)))
>endef
>
>$(eval $(call add_c_src, frmts/ceos, ceosopen.c))
>$(eval $(call add_c_src, frmts/ce
On Mon, 2022-01-24 at 19:09 +0100, Adam Tuja wrote:
> It doesn't matter how with many levels above current directory the
> path has (../ ../../ ...), it's still the same.
Suffix rules are very limited: this is why pattern rules were invented.
As long as you're happy with creating the object file
On Mon, 2022-01-24 at 21:27 +0100, Adam Tuja wrote:
> SRCS = a.c b.c ../c-1up.c
> OBJS = $(SRCS:.c=.o)
>
> .c.o:
> $(CC) $(CFLAGS) -c -o $@ $<
>
> $(PROG): $(OBJS)
>
> Now, when I understand it, it works. It's not the same thing as
> objects are placed beside source files but step forwar
On Fri, 2022-01-28 at 01:09 +0100, Alejandro Colomar (man-pages) wrote:
> I'd like make to warn about this. It took me a while to debug
> a Makefile bug, which I thought was not happening, since make should
> have warned me. Isn't this supposed to trigger the warning?
In previous versions of GN
On Fri, 2022-02-04 at 09:13 +, Sergei Trofimovich wrote:
> 1. Enable parallel builds by GNU make by default
>
> 2. Do not run dependencies in deterministic order by default:
GNU make (unlike Ninja) is bound by the POSIX standard in terms of its
behaviors. The POSIX standard makes very clear
Nice work!
On Sat, 2022-02-05 at 22:04 +, Sergei Trofimovich wrote:
> Some high level TODOs:
For this amount of change it's likely that you'll need to provide
copyright assignment paperwork. Let me know if you'd like more details
about this.
> - No documentation for the optin yet.
This fea
OK, someone posted a question to SO and that led me to an hour or more
of banging my head against a wall trying to understand what's
happening... and I can't.
The problem is that the user would like to invoke $(shell ...) and
capture errors, even errors that the program being run doesn't exist.
T
On Sun, 2022-02-06 at 20:18 +0300, Dmitry V. Levin wrote:
> 4175643 write(2, "/bin/sh: bad-program: command no"...,
> 40) = 40
> 4175640 <... read resumed>"/bin/sh: bad-program: command no"..., 200) = 40
> 4175640 read(5,
> 4175643 +++ exited with 127 +++
> 4175640 <... read resumed>"", 160)
On Sun, 2022-02-06 at 15:21 -0500, Paul Smith wrote:
> I'm not sure this is correct. I will need to think about it.
I decided this was a bug and changed the behavior for the next release.
is that make was printing the
_stdout_ of the invoked shell to make's stderr, if the shell exited
with code 127 (see the source I mentioned previously).
> On Sun, Feb 6, 2022 at 4:48 PM Paul Smith wrote:
> > I decided this was a bug and changed the behavior for the next
> > re
On Sat, 2022-02-05 at 11:24 +0100, Helge Kreutzmann wrote:
> I'm now reporting the errors for your project. If future reports
> should use another channel, please let me know.
This channel is fine, but please always do include the release of GNU
make that you're looking at when you submit changes
On Mon, 2022-02-07 at 18:18 +0100, Helge Kreutzmann wrote:
> > This channel is fine, but please always do include the release of
> > GNU make that you're looking at when you submit changes (run "make
> > --version").
>
> This I don't know. I receive the man pages from Fedora, SUSE,
> Archlinux, De
On Mon, 2022-02-14 at 18:54 -0500, Dennis Clarke wrote:
> variable 'plugin_is_GPL_compatible' [-Wmissing-variable-declarations]
This is happening because you're adding extra compile-time options to
the standard GNU make build, and those options are getting passed
through to the test suite.
Most l
On Fri, 2022-02-18 at 10:18 +0100, Magnus Ihse Bursie wrote:
> make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should
> be 24!
>
> This effectively turns the highly parallelized builds into
> single-threaded builds, and is absolutely detrimental for
> performance. :-( On the flip si
On Sat, 2022-02-19 at 17:40 +0200, Eli Zaretskii wrote:
> > From:
> > Date: Sat, 19 Feb 2022 14:25:47 +0100 (CET)
> >
> > Problem is wisible on follow example of file Makefile.win:
> >
> > all :
> > echo $(pkg-config --libs glib-2.0)
>
> This is wrong, you want
>
> all :
> echo
On Mon, 2022-02-21 at 08:59 +, Edward Welbourne wrote:
> and that's assuming a 32-bit int; the signed range is from -
> 2,147,483,647 to 2,147,483,648. However, may I suggest the following
> (which I know included in the GPL'd cfengine sources at some point):
This computation is already inclu
On Mon, 2022-02-21 at 15:56 +0100, Magnus Ihse Bursie wrote:
> I'm trying to built it from source right now (and it does not seem
> complicated), but even so, an official binary makes sure I'm not
> introducing any issues from my local build environment.
There is no such thing as an "official bi
On Mon, 2022-02-21 at 08:59 +, Edward Welbourne wrote:
> and that's assuming a 32-bit int; the signed range is from -
> 2,147,483,647 to 2,147,483,648. However, may I suggest the following
> (which I know included in the GPL'd cfengine sources at some point):
This computation is already inclu
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote:
> That coped with -nj --no-print-directory on the one version of Make
> that I tested it with, but I don't know how portable that would
> prove.
Modern versions of make guarantee a canonical format of MAKEFLAGS such
that you can parse them rel
On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote:
> Maybe putting it in the form of a patch on the latest git source will
> help it over the finish line:
I'm OK with adding some short text about this into the man page. As
David mentions it may be important enough to do that since command
bei
On Fri, 2022-03-18 at 21:12 +, Lahfa Samy wrote:
> I've reported this bug anonymously :
> https://savannah.gnu.org/bugs/index.php?62200 and would like to
> receive updates/comments on it by mail on my Savannah account, I
> don't know if the bug report could be assigned to me or the "posted
> b
Thank you for the patch.
It's most helpful if you can provide an example of the warning you're
trying to address, when you send the patch.
Cheers!
On Sat, 2022-03-19 at 19:42 +0800, boxues...@126.com wrote:
> From: wnh <545934...@qq.com>
>
> Adjust header file order in src/remote-cstms
On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote:
> For the record, I’ve thought of a sort-of-solution to the “would you
> have Make parse the shell command” question over the weekend. If the
> sub-make was called through a function rather than a variable, the
> whole issue could be a lot mor
(We generally prefer to use inline replies on the GNU lists, rather
than top-posted replies, thanks)
On Mon, 2022-03-21 at 13:22 +, Ambrus Sumegi wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call to
On Fri, 2022-04-01 at 16:06 +0800, calvin wrote:
> "Flags" should be translated to "标志" not "旗标" in Chinese
Thanks for your interest! All GNU make translations are handled
through The Translation Project:
https://translationproject.org/html/welcome.html
Please report any issues to the GNU mak
On Wed, 2022-04-20 at 21:36 +0800, Eliza Tan via Bug reports and
discussion for GNU make wrote:
> Ｈow are you ?
Sorry, this got approved in moderation when it shouldn't have been.
I applied both of these patches, thanks!
On Tue, 2022-05-10 at 15:03 +0200, Gisle Vanem wrote:
> SHELL := env "PATH=$(PATH)" /bin/bash
Well, I dunno. The problem is that at some point you have to choose
which command to use to invoke something. The SHELL variable is
intended to contain a shell program that make will exec(). Here you'r
On Tue, 2022-05-10 at 22:45 +0200, Michael Lehn wrote:
> But not on the Linux boxes there make always rebuild everything. On
> all machines I am using GNU Make.
This is because whatever GNU/Linux distribution is being used, has
configured their binutils so that ar is in "deterministic mode" by
def
On Tue, 2022-05-17 at 14:00 -0700, Jacob Kopczynski wrote:
> I'm unsure whether this is a bug or just undocumented, but I found a
> confusing interaction in a simple Makefile:
You are misreading the documentation. I will quote:
> A normal prerequisite makes two statements: first, it imposes an
>
On Tue, 2022-05-17 at 17:20 -0400, Paul Smith wrote:
> this says two things: first, that b and c will both be rebuilt (if
> necessary) before a's recipe is started,
I guess I should be more clear about the "(if necessary)". What I mean
is the same as if you had run "ma
On Tue, 2022-05-17 at 22:32 +, Martin Dorey wrote:
> > all your targets are .PHONY, and thus are always rebuilt anyway
>
> If you "make down", the rule for "down-clean" doesn't run. They're
> only rebuilt if something causes them to be considered.
>
> > order-only prerequisites are totally
On Wed, 2022-05-18 at 10:22 -0700, Jacob Kopczynski wrote:
> I believe I understand. The name "order-only" is highly misleading
> and should be changed - it does considerably more than "only"
> "order"; the only thing it does not do is check the timestamp.
As described in the docs there are only t
On Wed, 2022-05-18 at 14:36 -0700, Jacob Kopczynski wrote:
> The thing that the docs refer to as "impose order" is not a single
> thing, but two. I would characterize a normal prerequisite as doing
> three things rather than two:
> - update-marking: cause a target to be marked out of date if the
>
On Sat, 2022-05-21 at 19:06 +0200, Alejandro Colomar wrote:
> By "once all children are complete" you are implying the "existence"
> of the children (which make(1) doesn't really check, but one can
> think of it as if it did).
Perhaps that's the confusion. Make doesn't care about files at all per
On Sat, 2022-05-21 at 12:17 -0700, Valery Tolkov wrote:
> Exact target file doesn't matter, all files give the same error. If I
> do a clean build without any existing targets, it works. But second
> time it fails again.
>
> > ...
> > Must remake target `bin/dbg/clr/clr.o'.
> > clang++ --config ./
On Sat, 2022-05-21 at 14:34 -0400, Dmitry Goncharov wrote:
> On Sat, May 21, 2022 at 12:25 PM Paul Smith wrote:
> > Maybe what you're saying is that make should throw an error or
> > warning if you try to add an order-only prerequisite to a phony
> > target, tellin
On Wed, 2022-05-11 at 08:00 +0200, Gisle Vanem wrote:
> The crash and wild call-stack seems to be caused
> by an overflow to 'sprintf(sh_path, ..)'. But replacing
> with 'snprintf()' works w/o any crash:
I applied changes based on this: some didn't need sprintf() at all; the
rest I used snprintf()
On Sun, 2022-06-19 at 08:47 +0300, Eli Zaretskii wrote:
> > I do have a memory that some versions of Visual Studio, up until
> > relatively recently, have non-standard implementations of
> > snprintf()
> > but hopefully it's standard enough to manage this.
>
> If we now rely on ANSI-standard behav
I'm trying to decide what the future is for GNU make's "build.sh"
bootstrapping script. As you may recall, this script is provided to
allow GNU make to build on systems which don't already have an instance
of make installed. Its goal is to build the first make binary, without
of course all the fanc
On Sun, 2022-06-26 at 02:14 +0200, Henrik Carlqvist wrote:
> Would this "old version of make" have to be GNU make?
It would need to be some version of make that is supported by automake.
As far as I'm aware, automake-generated makefiles are currently
intended to run with any POSIX-compliant vers
On Sun, 2022-06-26 at 08:41 +0300, Eli Zaretskii wrote:
> It is sad that Gnulib maintainers aren't prepared to cater to a GNU
> project, and an important one such as Make. These are special
> requirements that only a handful of GNU project could ever have, and
> for good reasons, so supporting the
On Sun, 2022-06-26 at 07:34 +0100, Sven C. Dack wrote:
> 3. Allow to build a minimal Make executable, which provides basic and
> traditional Make functionality and does not rely on gnulib, and then
> use it as a bootstrap.
It's certainly a possibility. But there is already so much ifdef etc.
in G
On Sun, 2022-06-26 at 17:39 +0300, Eli Zaretskii wrote:
> > The problem is that the process for "make-less" systems in the past
> > has been: run configure, then run build.sh. But we won't be able
> > to use the environment created by configure in this "new" build.sh,
> > because it works in tande
On Sun, 2022-06-26 at 16:57 -0400, Dmitry Goncharov wrote:
> Have you considered to to avoid glob from gnulib? Make has its one
> impl of glob which it uses on certain systems.
> We could use this impl and maintain it on all systems.
While the original issue came up WRT glob, in actuality the prob
On Sun, 2022-06-26 at 22:00 -0400, Dmitry Goncharov wrote:
> What was the original driving force to introduce build.sh?
As mentioned, the goal of "build.sh" is to allow systems without an
already-existing make program to bootstrap themselves, by providing a
way to build GNU make without using "mak
I prefer to do the review via email rather than in the Savannah bug
tracker which has pretty annoying markup.
I would appreciate a somewhat comprehensive commit message or ChangeLog
for this set of patches, at least explaining some of the less obvious
modifications.
> +set -x
> +if [ ! ${PLATFORM
On Sat, 2022-06-25 at 17:47 -0400, Paul Smith wrote:
> This leaves me with two options:
>
> 1. Stop using gnulib, or at least sharply limit the modules we
> will include to those with trivial-enough configurations.
> 2. Abandon the build.sh script and require an existing ma
On Thu, 2022-07-14 at 14:16 +0200, Alejandro Colomar wrote:
> How can $localstatedir be $prefix/var and at the same time
> $runstatedir be /var/run (notice no prefix) if it is defined as
> $localstatedir/run.
This I don't know about: it might be a problem in the description.
> Since the FHS doesn
On Tue, 2022-07-19 at 20:26 +0200, Jean-Baptiste Poittevin wrote:
> a% b%: %
> cp $< $@
This rule is not well-formed. By declaring two patterns as targets,
you are telling make that your recipe will build both targets after
successfully being invoked one time.
If your recipe doesn't actu
On Tue, 2022-07-19 at 21:00 +0200, Jean-Baptiste Poittevin wrote:
> Well, allow me to cite the documentation linked :
>
> This is a behaviour which seems reasonable to me, sufficiently
> consistent for me to try to implement it. It is somehow sad that the
> same rule is not applicable for pattern
So after the changes I made to allow exporting environment variables to
subshells, I wanted to work on the issues we have with jobserver pipes
getting confused when you run make in unexpected ways such as inside a
shell function or in a recipe line which is not considered a submake.
There are at l
On Wed, 2022-07-20 at 00:47 -0400, Dmitry Goncharov wrote:
> On Tue, Jul 19, 2022 at 6:13 PM Paul Smith wrote:
> > There are at least two Savannah bugs about this very subtle and
> > annoying issue.
>
> Do you mean that jobserver-auth is present in the child env, even
> t
On Wed, 2022-07-20 at 20:33 -0400, Dmitry Goncharov wrote:
> if we take a step back, what is the problem? The problem is the
> presence of jobserver-auth in MAKEFLAGS in the non recursive case.
> You already implemented a solution which sets jobserver-auth=-2,-2.
> Another option is to remove jobse
On Thu, 2022-07-21 at 10:23 -0400, Paul Smith wrote:
> 6) There is another issue with setting blocking / non-blocking read
> on the jobserver fds. I can't remember if there's a Savannah bug or
> not about this, but changing the blocking/non-blocking status on a fd
> i
On Fri, 2022-07-22 at 14:05 +0200, Alejandro Colomar wrote:
> As the word suggests, as pre-requisites are satisfied before a given
> target, post-requisites would be satisfied _after_ a given target.
The way I can see this being implemented without a very significant
amount of work, would be for
On Mon, 2022-07-25 at 09:06 +, Edward Welbourne wrote:
> On 7/22/22 16:20, Paul Smith wrote:
> > > So, after all the "normal" goal targets were completed make would
> > > proceed to run any "extra" goal targets that were added as part
> > > of
On Sun, 2022-07-31 at 11:45 +0200, Alejandro Colomar (man-pages) wrote:
> > If some new post-requisite "baz" was found while building either
> > "foo" or "bar", it would be built after those and be as if the user
> > had invoked "make foo bar baz".
>
> What if one runs `make -j foo foo2` and both
On Tue, 2022-08-09 at 17:38 +0200, Ibrahim Salma wrote:
> Hi, i am having problem with makefile or make command can you please
> help me it's giving me an error message like this:
>
> collect2.exe: error: ld returned 1 exit status
> make: *** [Makefile:2: all] Error 1
This is not the error messag
On Wed, 2022-08-10 at 04:32 +0800, ljh wrote:
> make manual / 10.2 Catalogue of Built-In Rules / Linking a single
> object file
The example in the manual is wrong. The output you're getting from GNU
make is correct.
The reason is that the implicit rule that make chooses for the rule:
x: y.o z
On Tue, 2022-08-09 at 16:45 +0200, Gisle Vanem wrote:
> So does a "foo (arg1, arg2, arg3)" becomes one
> argument due to the parenthesis or something?
I agree it's strange. I'm not sure I agree with the change proposed in
the patch in the Savannah bug: modifying the way all function arguments
are
On Thu, 2022-08-11 at 01:58 +0800, ljh wrote:
> I have three c source files: x.c, y.c, z.c and I name x as the target
> on left. Can I put x.o in the prerequisites on the right too? Are
> they the same, with or without x.o in the prerequisites on the right?
>
> x: y.o z.o x.o # with x.o
I
On Fri, 2022-08-12 at 02:37 +0800, ljh wrote:
> Aren't the order of compiling object files of first two rules
> certain?
The POSIX standard for make mandates that prerequisites are tried by
make in the order they are listed in the prerequisite list, with the
exception that implicit rules will prep
On Wed, 2022-08-10 at 19:08 +, Katherine Pata wrote:
> I often find myself using makefiles to handle things like project
> linting, container images, various scripts, initiating tests, and
> other misc tasks. Sometimes these include tasks that have real
> dependencies that make should keep trac
On Mon, 2022-08-15 at 22:24 -0400, Dmitry Goncharov wrote:
> make-4.3 lets the user control (via presence or absence of +) if a
> particular sub-process should participate in the jobserver business.
> The current master, on the other hand, is "everyting is up to the
> sub-make".
> E.g.
> all:; make
Hi all.
I would like to work on putting out a new release of GNU make. I've
fixed, or merged patches for (thanks especially to Dmitry) most of the
issues that I had in mind for this release, except one: I'd really like
to fix the problem we currently have with handling fatal signals (like
SIGINT)
On Sun, 2022-09-04 at 00:28 +, Martin Dorey wrote:
> https://git.savannah.gnu.org/cgit/make.git/commit/configure.ac?id=079
> 3658c09a8f33581dae6dfbe2483ea279e72b1
>
> ... imposed a dependency on autoconf 2.71.
I'm not sure if there's a need for this new autoconf version or not, I
can look at
On Sun, 2022-09-04 at 01:54 +, Bjarni Ingi Gislason via Bug reports
and discussion for GNU make wrote:
> This causes failure when compiling.
What is the failure? I don't get any failures. I do see the output
here, but they are are just notes / warnings. Everything still works.
If you see
On Mon, 2022-09-05 at 00:16 +, Bjarni Ingi Gislason via Bug reports
and discussion for GNU make wrote:
> The compilation failed because I had an unclean git repository.
>
> My compilation creates a lot of warnings, which could be reduced if
> the header files were fixed
>
> 131 [-Wall
On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote:
> I started testing master recently and hit
> https://savannah.gnu.org/bugs/?63016
> which prevented doing any more testing.
Just curious: why does this prevent doing any more testing?
That issue needs to be carefully considered. In the previou
On Tue, 2022-09-06 at 18:59 +0100, Sam James wrote:
> When we started testing in Gentoo (not unleashed onto users),
> we had several failures that looks liked this almost immediately.
I see, thanks. I will look at this tonight. Clearly this change
introduces too severe a regression to accept as-
On Mon, 2022-09-05 at 03:47 +0100, Sam James wrote:
> I started testing master recently and hit
> https://savannah.gnu.org/bugs/?63016
> which prevented doing any more testing.
Hopefully this is fixed. It works for the examples given anyway.
I also downgraded the required version of autoconf to
On Sat, 2022-09-10 at 23:12 +0300, Fosil Crypto wrote:
> ubuntu@ip-172-31-95-154:~$ make ncdu gcc git jq chrony liblz4-tool -y
> make: invalid option -- 'y'
This is not a bug.
You are just invoking make incorrectly.
On Sun, 2022-09-11 at 11:02 +0200, Toralf Förster wrote:
> make[1]: *** Cannot open jobserver
> /var/tmp/portage/mail-client/s-nail-14.9.22/temp/GmQBwhVQ: No such
> file or directory. Stop.
It means someone or something deleted this file, while make was
running.
Maybe there's something in that
On Sun, 2022-09-11 at 11:02 +0200, Toralf Förster wrote:
> make[1]: *** Cannot open jobserver
> /var/tmp/portage/mail-client/s-nail-14.9.22/temp/GmQBwhVQ: No such
> file or directory. Stop.
You also should be able to get back the old behavior by adding the
--jobserver-style=pipe option to your m
On Sun, 2022-09-11 at 17:16 +0200, Toralf Förster wrote:
> make: invalid shuffle mode: '1662909020r'
Hm. Wonder where that "r" came from. I will look.
Oh I see it looks like an off-by-one buffer size error. Will fix,
thanks.
On Sun, 2022-09-11 at 12:19 -0400, Paul Smith wrote:
> On Sun, 2022-09-11 at 17:16 +0200, Toralf Förster wrote:
> > make: invalid shuffle mode: '1662909020r'
>
> Hm. Wonder where that "r" came from. I will look.
>
> Oh I see it looks like an off-by-o
On Sun, 2022-09-11 at 12:52 -0400, Paul Smith wrote:
> I'll look at little further.
Oh I see. This is definitely a bug in the glibc build system, not in
GNU make.
I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=29564
On Tue, 2022-09-13 at 07:31 +0200, Frank Heckenbach wrote:
> Is the last sentence grammatically correct? I'm not a native
> speaker, but I'd have expected "a more unreliable way" or "a less
> reliable way".
This was rewritten a few times and meant to be "a less reliable" but I
fat-fingered it. Wi
On Thu, 2022-09-15 at 14:00 +0100, Sam James wrote:
> > Very preliminary results (only mild testing done so far)
> > but the only failure I've hit thus far is autoconf-2.71:
> > https://bugs.gentoo.org/869257.
> >
> > I'll continue testing.
>
> It's been very quiet indeed, which is good news.
Th
GNU make is a tool which controls the generation of executables and
other non-source files of a program from the program's source files.
You can learn more at: https://www.gnu.org/software/make/
--
On Thu, 2022-09-22 at 10:54 +0200, Andreas Schwab wrote:
> The issue is that the bison rule says it creates a %.output file, but
> doesn't actually do that.
>
> %.tab.c %.tab.h %.output: %.y
> @$(VECHO) BISON $@
> $(BISON) -b $(basename $(basename $@)) -d $<
>
> Note that no targe
On Thu, 2022-09-22 at 14:13 +0100, John Graham-Cumming wrote:
> $ sw_vers
> ProductName: macOS
> ProductVersion: 12.6
> BuildVersion: 21G115
>
> $ ./make -v
> GNU Make 4.3.90
>
> $ cat Makefile
> $(info $(wildcard foo))
>
> $ rm -f foo
> $ ./make
> zsh: segmentation fault ./make
Hm, I cannot
1101 - 1200 of 1499 matches
Mail list logo
