On Mon, 2006-12-25 at 23:58 +0800, Dan Jacobson wrote:
> Doesn't look like I will get anywhere with filenames with colons in them:
> mkallexisting:.???.t .*[:-]*.t .Current_events.t
> Makefile:107: *** multiple target patterns. Stop
https://savannah.gnu.org/bugs/?112
--
On Fri, 2007-01-05 at 14:41 +0100, [EMAIL PROTECTED] wrote:
> >Fix applied.
>
> Could you commit the fix into CVS?
I definitely can, but is that really useful? The current state of the
CVS HEAD is pretty pre-alpha: it's right in the middle of a lot of code
rework.
It seems to me that the safes
On Mon, 2007-01-08 at 22:26 -0500, Ken Takusagawa wrote:
> In main.c we have
>
> jobserver_fds->list[0] = xmalloc ((sizeof ("1024")*2)+1);
>
> sprintf (jobserver_fds->list[0], "%d,%d", job_fds[0], job_fds[1]);
>
> Shouldn't xmalloc get a "+2" instead of "+1"? 1 for the comma, and
>
On Tue, 2007-01-09 at 10:32 +, James Coleman wrote:
> Ken Takusagawa wrote:
> > For reasons I haven't completely triaged yet, I've been having my
> > parallel makes die with
> > "read jobs pipe: Resource temporarily unavailable. Stop."
>
> All memory on machine might be used up (real memory +
On Wed, 2007-01-10 at 01:53 -0800, Howard Chu wrote:
> An essential design choice. This stuff relies on reads and writes of the
> job_fd being atomic and the writes never blocking. POSIX guarantees a 4K
> buffer for pipes. Perhaps the code should check the resource limit and
> complain if the -
On Fri, 2007-01-19 at 20:01 +0100, Dirk Heinrichs wrote:
> I'm using GNU make 3.81 (on Linux, if this is important) and see strange
> behaviour in parallel builds with the following Makefile:
>
> file1.txt file2.txt: file.in
> cat $< >file1.txt|tee file2.txt
>
> test: file1.txt file2.txt
On Sat, 2007-01-20 at 17:35 +0100, Dirk Heinrichs wrote:
> So if make behaves correctly in the parallel case, does this mean that the
> non-parallel case is wrong?
??
No, both are correct.
In the non-parallel case, make examines the first target and its
prerequisites and sees that it needs to
This message is mainly for Eli but anyone else who uses GNU make on
Windows might have an opinion.
I'm working on ensuring that the test suite works on Windows (some of
that means disabling tests until someone has a chance to rework them to
be more portable, unfortunately :-/).
I came across a te
On Thu, 2017-06-01 at 17:41 +0300, Eli Zaretskii wrote:
> > I'm not sure about this implementation (performance-wise) but
> > leaving
> > that aside, I don't understand why this code is ifdef'd out on
> > Windows.
>
> Well, it's your code, or so it seems ;-) And it was always ifdef'ed
> away on
On Wed, 2017-05-31 at 19:48 -0400, Paul Smith wrote:
> I'm working on ensuring that the test suite works on Windows (some of
> that means disabling tests until someone has a chance to rework them to
> be more portable, unfortunately :-/).
I've pushed these changes.
Note tha
On Sun, 2017-05-28 at 10:40 +1000, Robert Durkacz wrote:
> So I am suggesting that if we must have "export" in make, then the
> workings of "make -n" should be upgraded to report any exports that
> are set up.
"make -n" is primarily an interactive debugging/informational tool
letting the user know
Please choose just one GNU make mailing list to ask questions on: it
gets confusing if multiple lists are involved.
On Mon, 2017-06-05 at 11:08 +, Ramya S Ganesh (RBEI/ETC5) wrote:
> We tried executing make scripts using 4.1 version of make in Windows
> 7 PC and it took a reasonable amount of
On Tue, 2017-06-13 at 10:33 -0500, Brett Stahlman wrote:
> I don't see anything in the Make docs that guarantees prerequisites
> will be processed in left to right order. Opinions on the web seems to
> be split into 2 camps:
>
> 1. Make always builds dependencies in left to right order, but a
> we
On Thu, 2017-06-15 at 17:18 +0200, SF Markus Elfring wrote:
> define rule_pair =
> name::=$(1)
> $$(name:.ml=.cmo): $$(name)
> $$(OCAMLC_CMD) -c $$<
>
> $$(name:.ml=.cmx): $$(name)
> $$(OCAMLOPT_CMD) -c $$<
> endef
>
> $(foreach x,$(SRC_without_mli),$(eval $(call rule_pair,$(x
On Sat, 2017-06-17 at 16:05 +0200, SF Markus Elfring wrote:
> my_test_command?=cat
>
> define my_rule=
> ${1:.in=.txt}: ${1}
> $${my_test_command} $$< > $$@
> endef
>
> $(eval $(call my_rule,MOTD.in))
>
> This result is fine. Please try the following approach out again.
>
> my_test_comm
On Sat, 2017-06-17 at 17:00 +0200, SF Markus Elfring wrote:
> It might also be expected that this simple example just can not work
> as intended because of a special typo (one dollar sign missing).
Well, as they say, GIGO :)
> Corrected example:
>
> my_test_command?=cat
>
> define my_rule_demo=
On Mon, 2017-06-12 at 15:17 +0800, Cao jin wrote:
> I find some tiny errors in "info make", as a non-developer, I want to
> know how to provide the patch? Do you accept patch email via "git
> send-email"?
Any form in which you'd like to provide them, is acceptable.
Thanks!
_
On Sat, 2017-06-17 at 20:21 +0200, SF Markus Elfring wrote:
> > > my_test_command?=cat
> > >
> > > define my_rule_demo=
> > > name::=${1}
> > > $${name:.in=.txt}: ${1}
> > > $${my_test_command} $$< > $$@
> > > endef
> > >
> > > $(eval $(call my_rule_demo,MOTD.in))
> >
> > Is there someth
On Sun, 2017-06-18 at 17:14 +0200, SF Markus Elfring wrote:
> > It would have been generated if you would have called make with a
> > command like:
> > LANG=C make --no-builtin-rules -f ../rule-check2.make MOTD.log
>
> I hoped that I do not need to specify another file name for such command
> var
On Sun, 2017-06-18 at 19:45 +0200, SF Markus Elfring wrote:
> i_compilation?=echo
> o_compilation?=echo
> a_generation?=$(o_compilation) 'Checked modules: '
>
> parsing_c.cma: ast_c.cmo token_annot.cmo
> $(a_generation) '$<' > $@
>
> %.cmi: %.mli
> $(i_compilation) '$<' > $@
>
>
On Sun, 2017-06-18 at 21:10 +0200, SF Markus Elfring wrote:
> > make will see if it can be created by using your first pattern rule;
> > that means it needs a file ast_c.mli.
>
> This could be appropriate eventually.
>
> I adjusted some make scripts in this software area because of special
> impl
On Sun, 2017-06-18 at 22:55 +0200, SF Markus Elfring wrote:
> > > It seems then that the original make scripts could treat more
> > > interface descriptions as optional somehow.
> >
> > Without know what your original makefiles said I can't comment on that.
>
> Does such a feedback indicate that
On Mon, 2017-06-19 at 19:45 +0200, Henrik Carlqvist wrote:
> On Mon, 19 Jun 2017 12:08:35 -0400 (EDT)
> Markus Elfring wrote:
> > The semicolon indicates at the end that the return value is ignored
> > there. I imagine that further data processing should usually only
> > be performed if this comma
On Tue, 2017-06-20 at 08:28 +0200, SF Markus Elfring wrote:
> The wording “… override a built-in implicit rule (or one you have
> defined yourself) …”might need another clarification. Does the
> distinction with explicit make rules result in special consequences
> here?
> https://www.gnu.org/softw
On Tue, 2017-06-20 at 14:19 +0200, SF Markus Elfring wrote:
> > This applies only to implicit rules, not explicit rules.
> > > Can an explicit make rule also be cancelled anyhow?
> > No.
>
> Thanks for this clarification.
>
> This distinction has got important consequences on how the different
>
On Tue, 2017-06-20 at 17:18 +0200, SF Markus Elfring wrote:
> I guess that it will be noticed once more that implicit rules will work
> in an other way than static pattern rules.
It's important to realize that even though the unfortunate choice of
naming implies otherwise, static pattern rules are
On Thu, 2017-06-22 at 09:36 +0200, SF Markus Elfring wrote:
> > modules_without_mli::=$(filter-out $(basename $(mli_sources)),$(basename
> > $(ml_sources)))
> > $(info modules_without_mli)
> > $(info $(sort $(modules_without_mli)))
>
> Now I observe that the test output occurs twice while I am tr
On Thu, 2017-06-22 at 13:01 +0100, Sven C. Dack wrote:
> You either have to restrict the number of jobs by giving an explicit
> count or by limiting it with a load average ( -l option) or use
> non-numerical make targets such as "t1 t2 t3 ..." or simply add another
> flag after -j to make.
> $
On Thu, 2017-06-22 at 15:56 +0200, SF Markus Elfring wrote:
> > As always, if you can't figure out what's going on running "make
> > -d" will help you more than we can.
>
> I wonder about the information “Re-executing[1]: make --no-builtin-
> rules -d” there.
> Unfortunately, I do not recognise so
On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote:
> > Date: Sun, 18 Jun 2017 17:42:51 +0300
> > From: Eli Zaretskii
> > Cc: alex...@gmail.com, bug-make@gnu.org
> > > I think the problem is that reap_children() is called after
> > > delete_child_targets, so the child jobs can still run
> > >
On Mon, 2017-07-24 at 14:03 +0800, Cao jin wrote:
> Could I know why it got ignored?
Not ignored... queued!
These changes will be in the next release. Thanks for the help!
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listin
On Tue, 2017-08-01 at 18:32 +0200, Ray Foulkes wrote:
> I am totally baffled as to what cc -o is doing there. Surely it
> should be ld?? and then the -o is for "output" i.e. create "edit" as
> an executable.
It's generally not recommended that you ever run the linker directly
unless you have speci
On Wed, 2017-08-02 at 20:03 +0100, Sven C. Dack wrote:
> Hello,
>
> try it with the following rules:
>
> test-%: $(eval FOO = BAR)
> test-%:
> echo $(FOO)
No, this doesn't do what the OP wants. The eval in the prerequisites
of the pattern is expanded immediately so this is identical to wri
On Wed, 2017-08-02 at 20:40 +0100, Sven C. Dack wrote:
> It's my understanding that we don't actually know what Benjamin wants to
> do, because nobody has asked. So I don't see how this would make me wrong.
>
> From his mail am I assuming he wants his Makefile to print "BAR" for a
> target "tes
On Wed, 2017-08-02 at 21:16 +0100, Sven C. Dack wrote:
> I suggest you turn your attention towards him and ask him what he
> wants.
The example in his question makes very clear what he wants: he wants a
pattern-specific variable assignment.
The solution you provided was not a pattern-specific var
On Wed, 2017-09-20 at 22:50 +0700, Vladimir Vlad wrote:
> Hello! I'm using GNU Make 3.82
> Built for i686-pc-mingw32 on Windows 7. I have a question about the
> behavior of this program. How does GNU make decide if it runs a line
> from a rule directly or via a batch file? I need a line to always
On Fri, 2017-08-11 at 13:44 +0200, Paolo Bonzini wrote:
> Overall, they provide a 15% improvement for my favorite testcase (QEMU's
> "no-op" build). These were first sent out last November, but there
> have been quite a few changes since then:
Hi Paolo. Thanks for these patches, they do look int
Thanks for this patch, Paul.
One question:
On Sun, 2017-09-10 at 09:40 -0700, Paul Eggert wrote:
> + /* Make sure the parent of "." exists and is a directory, not a
> + file. This is because 'lstat' on Windows normalizes the argument
> + foo/. => foo without checking first that foo is a
On Sat, 2017-09-23 at 23:27 -0700, Paul Eggert wrote:
> Yes, that sounds right. I copied that boilerplate from local_stat, so
> local_stat
> could be simplified too.
This is what I applied. Thanks!
commit e069300c3a1170285b050cc6543f7d32e5b0993e
Author: Paul Eggert
Date: Sun Sep 24 09:12:58
On Sun, 2017-09-24 at 09:16 -0400, Paul Smith wrote:
> On Sat, 2017-09-23 at 23:27 -0700, Paul Eggert wrote:
> > Yes, that sounds right. I copied that boilerplate from local_stat, so
> > local_stat
> > could be simplified too.
>
> This is what I applied. Thanks!
On Sun, 2017-09-24 at 11:29 -0700, Paul Eggert wrote:
> Paul Smith wrote:
> > + size_t plen = strlen (path);
> > +
> > + /* If path ends in /. make sure it is a directory. This is because
> > + 'lstat' on Windows normali
On Sun, 2017-09-24 at 15:43 -0700, Paul Eggert wrote:
> Paul Smith wrote:
> > I can't answer your question, but the previous version of this
> > function didn't do anything special with a "foo/" path, so if it
> > doesn't work here it didn't wo
On Fri, 2017-10-13 at 14:34 +, Elizabeth Thompson wrote:
> make
> NOT using recipe
>
> I have read & read GNU Make and have no answers.
>
> I modified the example on pg 24 of GNU Make
> foo : $(objects)
> cc -o foo $(CFLAGS) $(objects)
> The example does not even work, the recipe is ignor
On Sun, 2017-10-15 at 16:49 +0100, Rob W wrote:
> I think it only needs to test if the first character is not nul. This
> is the change:
Thanks that's a good change.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-m
On Thu, 2017-09-28 at 16:28 +1000, NeilBrown wrote:
> One of my Makefiles contains
> MAKEFLAGS += -j
>
> Prior to the above commit, this would cause make to run as if I had
> run
>make -j
>
> Since that commit, it appears to be ignored.
This is a bug clearly. I've been thinking about it t
On Tue, 2017-10-31 at 07:39 +1100, NeilBrown wrote:
> On Mon, Oct 30 2017, Tim Murphy wrote:
>
> > For my money -j is always a top-level setting. To have it per makefile
> > and then let makefiles depend on that behaviour would open the door to lots
> > of scary bugs.
I don't see what scary bug
On Thu, 2017-09-28 at 20:41 +1000, NeilBrown wrote:
> I dug into this a bit.
> The regression is caused because the 'j' flag now causes
> arg_job_slots to be set, rather than setting job_slots directly.
I pushed a fix for this.
___
Bug-make mailing list
On Fri, 2017-11-03 at 12:27 +1100, NeilBrown wrote:
> Actually...
> A few times when building the linux kernel I've received the message
>
> make[1]: warning: jobserver unavailable: using -j1. Add '+' to
> parent make rule.
>
> This isn't consistent so it is presumably only when some particular
On Thu, 2017-11-02 at 11:44 +, Earnestly wrote:
> Is this a genuine test failure or was this unintended?
I'm not quite sure how to answer that question: definitely I didn't
intend the test to fail :). And in fact, it doesn't fail for me. I
couldn't find anything that used the ".wait" option
On Fri, 2017-11-10 at 17:36 +0100, Akim Demaille wrote:
> in other words, cd respects my symlinks, but make -C resolves them.
These statements don't make sense to me: what does "respecting a
symlink" mean, and how is it different from "resolving a symlink"?
What I'm assuming you mean is that the
On Wed, 2017-11-08 at 14:30 +0100, Paolo Bonzini wrote:
> Another month, another email begging for an update??
These changes have been pushed into the Git repository, thanks very
much.
I needed to adjust some of the unit tests which were impacted by the
changes to the hashing function.
Also, I n
On Tue, 2017-08-22 at 17:21 +0100, Sven C. Dack wrote:
> here is an updated version of the patch improving the performance of
> the -l option. It's a diff against the current git master.
I installed a patch adding this behavior a week or two ago, although I
reworked it to avoid needing any changes
On Fri, 2017-11-03 at 15:24 +, Earnestly wrote:
> On Fri, Nov 03, 2017 at 09:50:50AM -0400, Paul Smith wrote:
> > I'm not quite sure how to answer that question: definitely I didn't
> > intend the test to fail :).
>
> Ah sorry, I meant this in regards to w
On Tue, 2017-11-07 at 13:43 -0500, Nick Bowler wrote:
> Is this behaviour intended? I noticed the manual says "make may take
> shortcuts that do not affect the results" but in this instance a change
> in results is definitely observed.
Well, technically "command" is not a valid POSIX shell built-
Hi all.
This morning I pushed a batch of changes to the GNU make package build
to remove a bunch of older, outdated methods of building GNU make. I
removed the NMakefiles, SMakefiles, Visual Studio project files, and
some of the outdated .bat files.
The goal is to provide three package build cap
On Sat, 2017-11-18 at 16:17 +, Earnestly wrote:
> However I am now getting:
Thanks for the good info on your version of make and GCC... but... can
you provide details on what operating system you're using? I can't
reproduce this on any of my systems so I'm just curious. Is it just
the newer
On Sat, 2017-11-18 at 18:35 +, Earnestly wrote:
> > Also curious: why does the build decide to compile/link the version
> > of glob that comes with make? If you're using glibc then it should
> > use the one that comes with glibc instead.
>
> Wasn't this specifically done to workaround make us
On Sat, 2017-11-18 at 21:19 +, Earnestly wrote:
> [I've also found that `make update' is apparently subject to `make -j4'
> race conditions resulting in errors like:
>
> wget: unable to resolve host address ‘cvs.savannah.gnu.org’
> make: *** [Makefile;1584: get-doc/fdl.texi] Error 4
I
I've rearranged the source tree for GNU make, moving all the source
files (other than glob) into a "src/" subdirectory. All the batch
files, makefiles, etc. have been updated for this new organization.
I've verified that things still build and check properly on GNU/Linux,
MacOS, and Windows (ther
On Sat, 2017-11-18 at 23:02 +, Earnestly wrote:
> > # if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION
> >
> > and see if that works.
>
> Yes! This solves the issue and it also solves the __stat issues as
> well.
I pushed a change that should allow this to work properly. Note it
ca
On Sun, 2017-12-03 at 17:39 +0200, Orgad Shaneh wrote:
> On Fri, Jun 23, 2017 at 2:59 AM, Paul Smith wrote:
> > On Tue, 2017-06-20 at 18:20 +0300, Eli Zaretskii wrote:
> > > > Date: Sun, 18 Jun 2017 17:42:51 +0300
> > > > From: Eli Zaretskii
> > >
On Mon, 2017-12-25 at 16:09 -0800, Yuri wrote:
> The easiest way to reproduce:
>
> 1. Have FreeBSD installed with the current version of ports
I'm not sure about others but I don't have FreeBSD installed, and I
don't particularly want to spend my holidays installing it.
A faster way for you to g
On Tue, 2017-12-26 at 09:59 -0800, Yuri wrote:
> Here are all lines where the variable ARCH appears in the makefile. ARCH
> doesn't get substituted. Renaming ARCH -> ARCHX changes the behavior to
> what is expected.
>
> ARCH:= $(shell uname -m | ...)
> OSTYPE := $(shell uname -s | ...)
> B
On Tue, 2017-12-26 at 12:29 -0800, Yuri wrote:
> On 12/26/17 11:37, Paul Smith wrote:
> > to the makefile right after you assign ARCH and see whether the
> > shell result is what you expect, and whether the ARCH assignment
> > here is what you expect.
> >
> > Also
On Tue, 2017-12-26 at 13:07 -0800, Yuri wrote:
> On 12/26/17 12:47, Paul Smith wrote:
> > Again, the "-p" option will tell you if that is so.
>
>
> With -p, ARCH appears in these lines:
>
> # automatic
> -*-command-variables-*- := SHARED=true LDFLAGS=-
On Tue, 2017-12-26 at 13:38 -0800, Yuri wrote:
> On 12/26/17 13:29, Paul Smith wrote:
> > Well, this clearly shows that the ARCH variable has been supplied
> > on the command line, NOT through the environment.
>
> Except, it was not!
It was... somehow.
> When I stop th
On Tue, 2017-12-26 at 14:12 -0800, Yuri wrote:
> pstree shows that this is the only instance of gmake in the system. The
> parent process is BSD make called by framework.
So maybe ARCH is set by BSD make on (one of) its command line(s), then
inherited by GNU make.
> So I am confident that
>
> 1
On Tue, 2017-12-26 at 19:44 -0800, Yuri wrote:
> On 12/26/17 19:38, Paul Smith wrote:
> > If the BSD Ports framework is setting some variables "as if" they
> > were provided on the command line,
>
> But there is no such thing as "providing something as if on
On Wed, 2018-01-03 at 05:07 +, Amruta Bhat (amrbhat) wrote:
> ' '!' -f /users/amrbhat/.no_makej -a '!' -f
> /nobackup/amrbhat/polaris_3_1/vob/ios/sys/.no_makej ']'
> + echo '/auto/binos-tools/bin/makej - No STEP supported MakeJ found -
> using SRG makej wrapper'
> /auto/binos-tools/bin/makej -
On Tue, 2018-01-16 at 09:13 -0800, David Boyce wrote:
> It looks like the touching not only destroys incremental build
> capability (expected and not an issue) but toggles the makefile into
> "developer mode".
>
> I'm not looking for any changes here, just wondering whether anyone
> knows which fi
On Wed, 2018-01-24 at 12:46 +0100, Phi Debian wrote:
> 1) I'd like that -jN do leave some foot print in the environment, OR
> better set a gmake internal variable (predefined name) with the number
> that as given.
> 2) I'd like o suppress the enter/leaving message.
> make: Entering directory '...'
On Wed, 2018-01-24 at 16:17 +0100, Phi Debian wrote:
> Ouch I was running 4.1 :) , will wait next distro roll :)
The support for adding --no-print-directory to MAKEFLAGS works now, and
has for a very long time.
It's only the -j option being added to MAKEFLAGS that needs 4.2 and
above.
Cheers!
_
On Tue, 2018-02-06 at 15:12 +0100, Hans Ottevanger wrote:
> It appears that this behavior is caused by the need to maintain the
> variable MAKEFILE_LIST. The names of all included makefiles are
> appended one by one to the ever growing string representing this
> variable.This also explains why memc
On Thu, 2018-02-22 at 10:53 +, dimp...@cs.ox.ac.uk wrote:
> While building a project (https://github.com/sagemath/sage)
> on Arch Linux (which provides Guile-enabled GNU make)
> we have encountered make crashes which look as follows
>
> make: symbol lookup error: /usr/lib/libguile-2.2.so.1: un
On Tue, 2018-03-13 at 21:47 +0100, Barath Aron wrote:
> I'd like to build projects on a system that lacks fork() and vfork()
> support, but has posix_spawn(). Would you implement an alternate version
> using posix_spawn() to spawn child processes?
I have looked into it before... for about 5 minu
On Mon, 2018-03-26 at 19:38 -0700, warnerme wrote:
> TEST_COREx := $(if ifeq ($(shell expr $(TEST_CORE) \< $(NUM_CORES)),
> 1), $(TEST_CORE), $(shell expr $(NUM_CORES) - 1))
> TEST_COREy := $(if ifeq ($(shell expr $(TEST_CORE) \>= $(NUM_CORES)),
> 1), $(shell expr $(NUM_CORES) - 1), $(TEST_CORE))
On Sun, 2018-04-01 at 13:18 -0400, Dennis Clarke wrote:
> '/usr/local/build/make-4.2.1_linux_4.15.12-genunix_i686.003/glob'
> gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT glob.o -MD -MP -MF
> .deps/glob.Tpo -c -o glob.o glob.c
> glob.c: In function 'glob':
> glob.c:581:23: warning: implicit declara
On Sun, 2018-04-01 at 14:54 -0400, Paul Smith wrote:
> The contents of the glob/ directory are actually taken directly from
> glibc (although at this point an extremely old version) not developed
> by GNU make.
Oh, or Martin's reply. I guess I'm getting really old since this
On Sun, 2018-04-01 at 16:56 -0400, Dennis Clarke wrote:
> So I could just lift that out of glibc 2.27 and drop it into the make
> source tree and have a go at it. Is that the idea here ?
You could try, but I'm not optimistic that it will just work.
I think the way forward is to get the latest
On Mon, 2018-04-02 at 10:02 -0400, Dennis Clarke wrote:
> Well sure ... however before I get there I am still baffled why this
> current release code won't work on an old 32-bit intel debian server?
My understanding of the issue is that there's a compatibility problem
with the newly-released versi
On Mon, 2018-04-02 at 13:55 -0400, Dennis Clarke wrote:
> Not sure what to do with that.
You may need this:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=193f1e81edd6b1b56b0eb0ff8aa4b41c7b4257b4
Or, latest from Git HEAD.
___
Bug-make mailing lis
On Wed, 2018-04-04 at 13:03 -0400, Dennis Clarke wrote:
> After all the vibrant discussion I was at least expecting a reply that
> says "okay .. so that works" or perhaps a "ver 4.2.2 patches?" or
> something.
Well, we thought it would work and it did work, and those fixes are in
the codebase... s
On Thu, 2018-04-05 at 00:26 +0200, Henrik Carlqvist wrote:
> On Wed, 04 Apr 2018 15:42:51 -0400
> Paul Smith wrote:
> > It does look like we need to make a new release soon.
>
> If so, is there anything I can do to get the functionality of my
> contributed patch in bug #51
On Thu, 2018-04-26 at 23:56 +0800, 積丹尼 Dan Jacobson wrote:
> > > > > > "EZ" == Eli Zaretskii writes:
>
> EZ> What version of Make do you have there? The latest versions already
> EZ> report the line numbers together with errors.
>
> make --version
> GNU Make 4.2.1
It's very possible that this
On Fri, 2018-05-11 at 13:23 -0400, Jim Anderson wrote:
> I'm attaching the following files for what looks to be a bug in make:
Hi Jim; thanks for your email. In general we prefer that the contents
be embedded in the mail itself rather than in attachments. Most
particularly the description of the
On Fri, 2018-05-11 at 16:46 -0400, Jim Anderson wrote:
> However, I do consider this a defect in the software, because it is
> removing an intermediate file that is actually needed. The default
> behavior is reasonable, but not being able to override, leaves me in
> this situation with poor alte
On Mon, 2018-05-21 at 08:36 +0200, Garreau, Alexandre wrote:
> Then I discovered --load-average, and I’m asking myself wether the
> optimum is -j n+1, -l 1.0, or -l n or n+1?
IMO, there are too many problems with choosing any value as the default
value:
* It's not so simple to determine the numb
On Mon, 2018-05-21 at 08:20 +0200, Garreau, Alexandre wrote:
> For instance, if there’s an occurence of $(several words) in the
> makefile, and the variable “several words” isn’t defined (that’s not a
> natural thing to do anyway), taking its firstword, and being equivalent
> to $(call several,word
On Mon, 2018-05-21 at 08:12 +0200, Garreau, Alexandre wrote:
> Also I was wondering… would there be some possible mechanism so that
> a filename with spaces in it might be appropriatedly treated by
> implicit rules? or is it intrinsic to, say, automatic variables
> splitting with spaces?
This is a
On Mon, 2018-05-21 at 18:17 +0200, Garreau, Alexandre wrote:
> On 2018-05-21 at 10:56, Paul Smith wrote:
> > A few releases ago I made it illegal to create variable names
> > containing spaces so the above makefile no longer works. My
> > intention at that time was to allow
On Mon, 2018-05-21 at 18:13 +0200, Garreau, Alexandre wrote:
> > There was a long discussion here a few years ago about a new
> > capability for handling special characters in filenames possible,
> > and I have a partial implementation that was not completed, of a
> > possible way to do this.
>
>
On Tue, 2018-06-05 at 11:24 +0200, Barath Aron wrote:
> I started to work on to replace fork() with posix_spawn(). I think it
> is not hopeless, so I though I make a try.
> I use the master ( git clone
> https://git.savannah.gnu.org/git/make.git ), which currently is:
Hi Barath; thanks for looking
On Thu, 2018-06-07 at 11:30 -0500, Brenton Chapin wrote:
> Tried to configure Linux kernel 2.6.26 on Lubuntu 18.04 with make 4.1
> and gcc 7.3.
> "make menuconfig" gives "No rule to make target menuconfig".
>
> With make 3.8 (Lubuntu 12.10), menuconfig works.
There is no make version "3.8". I as
On Thu, 2018-07-12 at 10:26 +0900, Masahiro Yamada wrote:
> $ make -j8 defconfig all
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> YACCscripts/kconfig/zconf.tab.c
> LEX scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfi
On Thu, 2018-07-12 at 13:55 +0900, Masahiro Yamada wrote:
> Please add V=1 to the build command, like this:
>
> $ make -j8 V=1 defconfig all
>
> It will emit _almost_ raw log.
At this time I don't have the resources to do this. It will take me
some time if you're going to wait for me.
> > Th
On Thu, 2018-07-12 at 14:51 +0900, Masahiro Yamada wrote:
> I attached information that might be helpful.
> Please take it FWIW.
The content you quote looks correct to me so if that's what's really in
the makefiles then the problem is a deeper mystery.
Can you clarify what version of GNU make you
On Mon, 2018-07-16 at 15:30 +0800, Zorro Lang wrote:
> > [root@fedoravm tmp]# ls -l
> > total 4
> > -rw-r--r--. 1 root root 206 Jul 15 14:58 Makefile
> > drwxr-xr-x. 1 root root 0 Jul 15 14:59 testdir
> > [root@fedoravm tmp]# cat Makefile
> > STRING1 = $(wildcard $(CURDIR)/[a-z]*/)
> > STRING2 =
On Mon, 2018-07-09 at 09:05 +0200, Aron Barath wrote:
> ---
Thanks for the work you put into this!
Unfortunately this change reveals some deeper problems that I will need
to address. Basically, the old code never really expected fork() to
fail: if it did we intended to just give up completely.
On Tue, 2018-07-24 at 16:04 -0600, Brian Vandenberg wrote:
> In a plugin I wrote I created a function with the following form /
> function:
>
> $ cat makefile
> ASDF := something
> $(timeit 100, ${ASDF})
> $ make
> makefile:2 Time taken: mean: 232, stdev: 81.719765
>
> make: *** No targets. Stop
On Wed, 2018-07-25 at 14:25 -0600, Brian Vandenberg wrote:
> > However, I'm not sure that this function is sufficiently generic to
> > be added as a built-in function. Can you provide use-cases for it?
>
> I suppose that depends on the definition of "sufficiently generic".
> The two definitions
701 - 800 of 1499 matches
Mail list logo
