Re: Immediate and deferred expansion documentation rewording

aluated. exp needn't itself appear again. From: Maris Razvan Sent: Tuesday, October 1, 2019 13:19 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: Immediate and deferred expansion documentation rewording * EXTERNAL EMAIL * Thank you for your answer.

Re: Immediate and deferred expansion documentation rewording

> I understand the following Apart from the word "cmake", that chimed with my understanding. > a completely different meaning than the one used in the previous sentences I think the meanings are consistent if "a section of a construct" is itself a "construct". > however one situations >

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #20, bug #49014 (project make): Surely Kurt was running with that? Mind, he didn't say. I haven't seen my Linux problem in the 2+ years since applying b552b0525198. ___ Reply to this item at:

[bug #56764] Different behavior of printf command executed from Makefile and from shell.

Follow-up Comment #3, bug #56764 (project make): [comment #2 comment #2:] > When make invokes printf it's assuming a POSIX shell, and running the /usr/bin/printf executable not the bash builtin. Look ma, no /usr/bin/printf: mad@shuttle:~/tmp/make-56764$ strace -f make 2>&1 | grep exec

[bug #56764] Different behavior of printf command executed from Makefile and from shell.

Follow-up Comment #1, bug #56764 (project make): I get similar, but that's because my login shell is /bin/bash: martind@swiftboat:~$ getent passwd martind | cut -f7 -d: /bin/bash martind@swiftboat:~$ ... while: lrwxrwxrwx 1 root root 4 Nov 8 2014 /bin/sh -> dash Make will default to using

Re: Feature request / patch: dependency-only prerequisites

> The target certainly also depends on the compiler frontend, the linker > backend and the Makefile itself It's unimaginable that it doesn't depend on compiler libraries and myriad compiler-provided header files too. Using header files in a compilation example would make the $(filter ...)

[bug #56420] Unclear wording or missing word

Follow-up Comment #1, bug #56420 (project make): The context, specifically the start of the previous paragraph: > If there are C compiler options that _must_ be used for proper compilation of certain files, do not include them in CFLAGS. ... > Do include the ‘-g’ option in CFLAGS, because that

Re: append assignment operator in target specific variable

Here's my understanding of the OP's three samples being run: $ cat Makefile.1 foo := val := 100 all : foo += $(val) all : ; @echo foo : $(foo) val := 200 $ make -f Makefile.1 foo : 200 $ cat Makefile.2 foo := val := 100 all : foo := $(val) all : ; @echo foo : $(foo) val := 200 $ make -f

Re: Memory leaks in Make

> It would be nice if Make cleaned up its resources before exiting. Would it? Linking all those blocks back on to free lists and coalescing adjacent ones doesn't take a long time but it takes more time than just tearing down the address space. It can be a reasonable economy for short-lived

Re: Erroneously not updating intermediate/secondary dependency

make kindaclean; make --debug=all says: Finished prerequisites of target file 'a-derived.src'. Prerequisite 'a.out' of target 'a-derived.src' does not exist. No need to remake target 'a-derived.src'. https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html#Chained-Rules

Re: Shell function and LD_LIBRARY_PATH

> Why ouch? Because it's unpleasant and wasteful to work in an environment where you're not trusted. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: Shell function and LD_LIBRARY_PATH

>> on a server, where I don't have root access Ouch. > using RPATH at link time Debian has a package called chrpath, supplying an executable of the same name which lets you change the RPATH later. That might be easier than doing battle with the underlying bash package's build rules. The man

[bug #20513] # still needs to be escaped in a function like $(shell)

Follow-up Comment #4, bug #20513 (project make): Back in the day, the Linux kernel makefiles, for example: /usr/lib/linux-kbuild-3.16/scripts/Makefile.lib ... defined a KBUILD_STR macro with a # escaped like this: c_flags= ... ... -D"KBUILD_STR(s)=\#s"

Re: Autotools requirements are too recent

I did warn you. > Fedora is know for having some of the most up to date tools. It must indeed be a cold day in hell, as I used automake 1.16.1 from Debian Buster. > there's no hope it can build where a newer GNU Make is truly needed Perhaps the widespread lack of this automake is what's

Re: Failed compile on Fedora 28, x86_64

> I *thought* we are supposed to avoid alloca in 2018. Amen brother. martind@swiftboat:~/download/make-git/src$ sgrep -w alloca | wc -l 115 martind@swiftboat:~/download/make-git/src$ Ugh. > I'm building 4.2.1 from the tarball. You'd have more luck from git, per:

[bug #54549] Segfault caused by makefile in make version 4.2.1

Follow-up Comment #1, bug #54549 (project make): Reproduced in yesterday's (or so) git: (gdb) bt #0 __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:62 #1 0x00411468 in hash_find_slot (ht=ht@entry=0x124d550, key=key@entry=0x1248820) at src/hash.c:108 #2

[bug #54529] [Makefile:5: foobar] Segmentation fault

Follow-up Comment #1, bug #54529 (project make): Easily put back but I think the bug reporting thing has eaten a tab. Using a semicolon rather than newline and tab would avoid that. I can't reproduce the crash. I'm using the latest from git. If I were you, I'd run it under valgrind, then

Re: Linux kernel 2.6.26, make 4.1, menuconfig: no rule

> try to determine what causes the difference in > behavior. If the OP did that and identified a bug and found a fix, perhaps the fix that stops the problem from happening in later versions, I can't see a new version of make-3.8x or of the Linux 2.6.26 kernel series being released to address

[bug #53597] Cross-compilation fails on GNU/Linux with GNU libc 2.27

Follow-up Comment #1, bug #53597 (project make): This old chestnut again, for the second time in as many weeks? The patch that closed the previous round was in: https://lists.gnu.org/archive/html/bug-make/2018-04/msg00018.html The TL;DR from elsewhere in the thread was that building from

RE: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

> checking whether closedir returns void... no > ./configure: line 9678: PKG_PROG_PKG_CONFIG: command not found > ./configure: line 9690: syntax error near unexpected token `GUILE,' > ./configure: line 9690: ` PKG_CHECK_MODULES(GUILE, guile-2.0, > have_guile=yes,' > debi686$ Perhaps it's:

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

> why this current release code won't work https://lists.gnu.org/archive/html/info-gnu/2016-06/msg5.html says make-4.2.1 is from 2016-06-11. In the email thread I cited previously, for what looked like the same errors, we see Paul writing, over a year after that release, on 2017-11-19, "I

RE: Documentation bug: mistaken transitive verb

> mistaken transitive verb I think we can take your testimony as a demonstration that it's an infelicitous phrasing, which is the kind of useful insight that wouldn't occur to at least this native English (and fluent make) speaker, but, for what it's worth, I don't think it's a grammatical

Re: Another fix in https://www.gnu.org/software/make/manual/make.html

I think the opposite. Isn't it saying that a rule for building .o from .c will work for such files in any directory, but a rule for building release/%.o from %.c will only work in the current directory? On Feb 9, 2018, at 08:30, Howard Johnson wrote: In this

[bug #52076] wildcard/glob should be sorted

Follow-up Comment #4, bug #52076 (project make): There must have been discussion about changing that setting, then removing it, documenting it and reapplying it. Perhaps I even vaguely remember it? You'd think it'd be easy enough to find. I did but I've spent a good ten minutes trying to find

[bug #51974] multiline (define/endef) containing target-specific assignments causes errors in /bin/sh

Follow-up Comment #4, bug #51974 (project make): I can't dispute Anonymous's advice, which was what I first thought of too, but I don't think it's clearly documented, neither in the GNU make manual nor in this vein of bugs, how makefile fragments like these are being parsed. Perhaps this example

RE: -n ignored

Ø Using GNU Make 3.81 in macOS 10.12. http://lists.gnu.org/archive/html/info-gnu/2006-04/msg0.html suggests that was released over a decade ago. I imagine that's still what Apple's shipping but perhaps it's time for you to visit https://brew.sh/. I doubt the behavior's changed but

RE: Targets directory name concatenation strangeness

You're trying to use an automatic variable in a scope where it doesn't have the value you want. make -p is how I'd debug such: martind@swiftboat:~/tmp/benjamin-cama-2017-08-03$ cat Makefile SUBDIR = $(@D) $(SUBDIR)/target-%: martind@swiftboat:~/tmp/benjamin-cama-2017-08-03$ make -n -p 2>&1 |

[bug #51527] Make race issue when MikTeX htlatex is used

Follow-up Comment #2, bug #51527 (project make): Numerous memory corruption bugs have been fixed in the 11 years since make 3.81, some with just the sort of input sensitivity you report here. One example: https://savannah.gnu.org/bugs/?40159 I only have anecdotal evidence but even Debian, who

Re: A Severe Problem with Make

I'm pretty confident that "the package" in question really is make. https://launchpad.net/ubuntu/+source/make-dfsg suggests that Ubuntu don't offer a prebuilt package of 4.2.1, the version the OP claims to have wanted, making a build from source plausible. That said, the directory name in the

[bug #51462] Double-colon dependencies are built serially with parallel make

Follow-up Comment #1, bug #51462 (project make): A google for that hash finds: https://savannah.gnu.org/bugs/?48057 ... in which a reversion of that commit is suggested. It's marked as a duplicate of: https://savannah.gnu.org/bugs/?47995 ... which is marked as fixed in 4.2.1, which is the

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #6, bug #51309 (project make): A theoretical argument is not what Paul meant by "actual results". Have you measured the time spent adding and removing the directory names in some realistic case? If not, then please do not advocate for making Make bigger..

[bug #51338] Support for construction patterns by make functions

Follow-up Comment #1, bug #51338 (project make): > the code which will be evaluated in the recipes can be configured by function call parameters You can do that today, no need for any enhancement. > I guess that I need to use the functionality “second expansion” then. No.

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #15, bug #49014 (project make): I've been running with the git head as of your 2017-06-04 request. The problem hasn't recurred for me. I don't think that means as much as it would have a few months ago because I've had less cause to run my

RE: Checking application of dependencies from make rules without recipes

>> I don't see why it makes a difference in how rule types should be ordered > A dependency graph is constructed by make scripts. I don't think that's relevant: a graph's topology isn't dependent on the order in which its arcs are enumerated. >> Only if an explicit rule does not exist will an

Re: [PATCH 1/2] Trivial correction on document

My native English speaker intuition says that "if it were" and "if it was" are both available there. https://english.stackexchange.com/a/146382 cites Huddleston and Pullum's grammar in agreement. Other answers suggest the "were" form is getting rarer, so maybe it's a good idea to change it,

RE: Checking software build tries for “commands.cmo”

Sorry for my fat-fingered phoning. >> Would you have it complain that commands.mli,v, RCS/commands.mli,v, >> RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing? > Not really in this use case. Did you tell make, then, to disable all of its default rules for creating

Re: Checking software build tries for “commands.cmo”

Would you have it complain that commands.mli,v, RCS/commands.mli,v, RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing? > Not really in this use case. Did you tell make, then, to disable all of its default rules for creating commands.mli or, for that matter, commands.cmo, by

Re: Checking software build tries for “commands.cmo”

Would you have it complain that commands.mli,v, RCS/commands.mli,v, RCS/commands.mli, s.commands.mli and SCCS/s.commands.mli were missing? > Not really in this use case. Did you tell make, then, to disable all of its default rules for creating commands.mli or, for that matter, commands.cmo, by

RE: Checking software build tries for “commands.cmo”

> I have noticed a moment ago that an interface description file was missing > somehow for the OCaml source file in this compilation attempt. ... > I wonder then that the make tool did not give me a direct clue for a failed > software dependency as I am used to in other cases. Would you have it

[bug #51159] pselect jobserver stuck at read does not reap children

Follow-up Comment #1, bug #51159 (project make): Is this part of: bug #49014: Zombies in parallel builds with pselect code But with the key missing ingredient - a diagnosis - and a fix? ___ Reply to this item at:

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #10, bug #49014 (project make): Matt's work around worked for my latest recurrence. I wonder if it gives us a clue as to the cause? I hadn't thought to try it and it's helpful not to have to kill the build, so thanks.

Re: thoughts and questions on order-independent Makefile method

I've had the same frustrations, though you've got further in some directions than I have. It feels like we want to be writing in a slightly higher level language. We could generate makefiles from this higher level language, but make seems close to what we want, if we're careful. This seems

RE: [bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

==22022== Address 0x4caf710 is 0 bytes inside a block of size 200 free'd ==22022==at 0x4A0804B: free (vg_replace_malloc.c:534) ==22022==by 0x41EC52: read_all_makefiles (read.c:210) That was helpful, thanks. Reproduced with: martind@swiftboat:~/tmp/make-50790$ cat first.make default:;

RE: Deadlock in signal handler

> What do you think about this issue? How can I fix it? Well titled, precise, concise and horribly plausible. A great write up then. One that I think deserves a bug report at https://savannah.gnu.org/bugs/?group=make, if you wouldn't mind. That fatal_error_signal handler looks repeatedly

[bug #49938] fdin might be (but isn't?) clobbered by vfork

URL: Summary: fdin might be (but isn't?) clobbered by vfork Project: make Submitted by: mdorey Submitted on: Mon 26 Dec 2016 10:42:49 AM PST Severity: 3 - Normal Item

[bug #49935] num_mkfiles uninitialized

URL: Summary: num_mkfiles uninitialized Project: make Submitted by: mdorey Submitted on: Mon 26 Dec 2016 10:16:55 AM PST Severity: 3 - Normal Item Group: Bug

[bug #49590] wildcard no longer give sorted output in version 4.2

Follow-up Comment #1, bug #49590 (project make): http://git.savannah.gnu.org/cgit/make.git/tree/NEWS Version 3.82 (28 Jul 2010) ... * WARNING: Backward-incompatibility! Wildcards were not documented as returning sorted values, but the results have been sorted up until this release.. If your

RE: Simpler example of pathological behavior of directory caching

one forever without being tracked down before, but I can think of one place. -Original Message- From: Paul Smith [mailto:psm...@gnu.org] Sent: Friday, October 07, 2016 05:07 To: Martin Dorey; Kyle Rose; bug-make@gnu.org Subject: Re: Simpler example of pathological behavior of directory caching

RE: Simpler example of pathological behavior of directory caching

> If you put the makefile in a different directory ... > Or if you list it explicitly but disable built-in rules It was sadly unclear to me that you'd done one of those with your: >> $ make >> touch target1 .. >> glob: target3 target10 target9 target8 target7 target6 target5 target1 >> target2

RE: Simpler example of pathological behavior of directory caching

I can reproduce it too: martind@swiftboat:~/playpen/kyle-rose$ rm -f target*; ~/download/make-git/make touch target1 touch target2 touch target3 touch target4 touch target5 touch target6 touch target7 touch target8 touch target9 touch target10 glob: martind@swiftboat:~/playpen/kyle-rose$ make

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #3, bug #49014 (project make): Happened to me again. All the zombies were preceded in the process tree by a make blocked on the read of job_fds[0] in the HAVE_PSELECT jobserver_acquire. I had, once again, sent the whole process group SIGSTOP and SIGCONT at some point.

[bug #49014] Zombies in parallel builds with pselect code

Follow-up Comment #1, bug #49014 (project make): I've had a couple of hung makes in the last couple of months where I've noticed a prominent number of zombies. I see my from-git make from 2016-06-11, reporting itself as 4.2.1, has HAVE_PSELECT=1 in config.status and imports that symbol from

[bug #48951] Grammar mistake in section 5.3.1

Follow-up Comment #1, bug #48951 (project make): Although this is reported against an old revision, the infelicity is still present in git: diff --git a/doc/make.texi b/doc/make.texi index 01bcec7..4fc1724 100644 --- a/doc/make.texi +++ b/doc/make.texi @@ -3909,7 +3909,7 @@ show : As a

[bug #48360] Environment variable doesn't loose specialness, although redefined

Follow-up Comment #1, bug #48360 (project make): By "specialness", I think you mean "whether it's exported". Adding "export CC" turns the first example into a BOOM case for me. Adding "unexport CC" stops the second example BOOMing for me. This seems well-behaved to me.

Re: ifeq and ifneq not working

TESTSRC depends on $@, an automatic variable set at the time of recipe execution. ifneq by contrast runs earlier. https://www.gnu.org/software/make/manual/html_node/Conditionals.html#Conditionals explains "Conditionals control what make actually “sees” in the makefile, so they cannot be used

RE: Parallel Build with GNU make

I'm not sure that I'll be adding anything that isn't a statement of the obvious but I can explain how we solve this in our environment. We have the subfolders specified in a variable, SUBDIRS. Another variable, BUILD_RECURSION_PREREQUISITES is synthesized from SUBDIRS to contain the like of

RE: Make page error.

Ø I believe "or" is misspelled as "ar". Thanks for your diligent reading, but this is a deliberate reference to https://en.wikipedia.org/wiki/Ar_(Unix). From: bug-make-bounces+martin.dorey=hds@gnu.org [mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Varun H Sent:

[bug #46193] Discussion of system crash behaviours

Follow-up Comment #1, bug #46193 (project make): Fail-stops aren't limited to crashes. Ctrl-Z and network splits sometimes stop make from removing a half-written target. At this shop, we aim to write rules that only write into temporary files, renaming them to the desired name once writing has

RE: Parallel make Order Algorithm

I have the feeling that the second algorithm has a bottleneck: The algorithm you describe is a feature of your makefile(s) rather than make. Make doesn't really know about the traditional three phases of a large C project that you describe. It's just as happy driving an assembler, preparing

RE: make doesn't take the shortest stem

Ø short stem 1 That's what I see from eg make-4.1.90 from git (2014-10-05). The NEWS file dates make-3.81 to 2006-04-01. From: bug-make-bounces+martin.dorey=hds@gnu.org [mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Meir BENAYOUN Sent: Monday, June 01, 2015 04:54

[bug #45211] Add option to MAKEFLAGS (How to set RM variable?)

Follow-up Comment #1, bug #45211 (project make): The claim being, I presume, that the second RM='' should either be RM='rm -f' or RM='rm', the latter only being the case if changing MAKEFLAGS takes effect implausibly quickly. It's the former with a Debian Wheezy make 3.81 (origin says default),

RE: Using hash instead of timestamps to check for changes.

I spent a few hours trying to work out how to fake this up with a secondary file whose modified time-stamp serves as up-to-date for the primary it represents. I imagine we're not alone, but perhaps an existence proof would have some value: we have generic makefile code that provides this

[bug #44660] possible buffer overflow?

Additional Item Attachment, bug #44660 (project make): File name: strcache.c.take2.patch Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?44660 ___ Message sent

[bug #44660] possible buffer overflow?

Follow-up Comment #1, bug #44660 (project make): Reproduced on amd64 with up-to-the-minute make from git. valgrind reports things going south starting here: martind@swiftboat:~/tmp/make-44660$ valgrind ~/download/make-git/make ==30211== Memcheck, a memory error detector ==30211== Copyright (C)

RE: Buffer overflow in orig/implicit.c

3.82 isn't the latest. It looks like someone beat you to it: Differences between revisions 3f6bb04e75e5a02f23339c9d4bec99b22d430803 and 6405534814f04899890a2d932db9a4985fd772fe: 2012-02-26 21:34:51 + psm...@gnu.org (6405534814f04899890a2d932db9a4985fd772fe) Check for possible buffer

RE: Make does not throw an error for target without a recipe?

Why is it trying to build target test.mk...??? That's explained by https://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles. Then it decides it was successful? For some value of successful. With your makefile: martind@swiftboat:~/tmp/batrick-2014-06-26$ make -f test.mk foo

RE: Make does not throw an error for target without a recipe?

Message- From: Patrick Donnelly [mailto:batr...@batbytes.com] Sent: Thursday, June 26, 2014 13:43 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: Make does not throw an error for target without a recipe? Hi Martin, On Thu, Jun 26, 2014 at 4:33 PM, Martin Dorey martin.do...@hds.com wrote

RE: Make does not throw an error for target without a recipe?

, June 26, 2014 14:06 To: Martin Dorey Cc: bug-make@gnu.org Subject: Re: Make does not throw an error for target without a recipe? On Thu, Jun 26, 2014 at 5:02 PM, Martin Dorey martin.do...@hds.com wrote: I'm afraid none of this exercise is helpful for solving the problem Perhaps putting my point

Re: GNU make 4.0 crashes on Solaris 8

The vsnprintf thing was (probably) fixed in git under http://savannah.gnu.org/bugs/?40361. From: Tom Kacvinsky [mailto:tom.kacvin...@vectorcast.com] Sent: Thursday, April 17, 2014 07:23 AM To: Bug-make@gnu.org Bug-make@gnu.org Subject: GNU make 4.0 crashes on Solaris 8 I have successfully built

RE: Excessive $(strip)

: Thursday, April 03, 2014 07:37 To: bug-make@gnu.org Subject: Re: Excessive $(strip) Martin Dorey martin.do...@hds.com wrote: this also removes the newlines. ... IMHO make 4.x has a too strict definition of white-space. http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html

RE: Excessive $(strip)

I'd say that make itself is sloppy wrt whitespace, where sometimes newlines are considered to be whitespace, othertimes not. ... the word family of functions do not. Nice example. The source seems to draw a distinction between isblank, terminology available, I learn, in C99, and the more

RE: Excessive $(strip)

this also removes the newlines. ... IMHO make 4.x has a too strict definition of white-space. http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html sayeth: In the POSIX locale, at a minimum, the space, form-feed, newline, carriage-return, tab, and vertical-tab shall be

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

Follow-up Comment #5, bug #40159 (project make): On a version (3.99.92) from Git the other day, the example's output ends with: Makefile:12: i Makefile:12: i make: Nothing to be done for 'dummy'. It exits with status zero. valgrind doesn't notice anything scary. With the make (3.81-8)

[bug #40159] Premature exit with incorrect error message, or garbage output characters.

Follow-up Comment #6, bug #40159 (project make): Debian's make 3.81-8.2, from Wheezy and Sid, behaves like Squeeze, as does make-3.82 built on Debian via Paul's instructions here. ___ Reply to this item at:

RE: Help:Stop compile due to Segmentation Fault Error

the problem is that Ubuntu (and Debian) ship a very outdated release of GNU make The current, recent Debian stable, Wheezy, ships with a version of make that it pleases Debian to call 3.81-8.2, per http://packages.debian.org/wheezy/make. Per the changelog link to

RE: Help:Stop compile due to Segmentation Fault Error

(Bcc: help-m...@gnu.orgmailto:help-m...@gnu.org - this is definitely a make bug) Ø part of Makefile So not enough for us to try to repeat it. It looked vaguely familiar and Google turned up something similar, sadly with no obvious resolution:

RE: [bug #39028] [patch] fix and uniformize four error messages

I think integer is meant instead of integral. Eg C99 uses integral as an adjective meaning of integers, per 1 b (1) from http://www.merriam-webster.com/dictionary/integral. My googling suggests that the OP's right, though, that the patched would be more widely understood. -Original

[bug #33958] Segfault in a 'define' with sort, foreach and newlines...

Follow-up Comment #1, bug #33958 (project make): I think the whitespace was preserved in the email to me. I could certainly reproduce the problem using the snippet from the mail in 3.82.90. But not in CVS. ___ Reply to this item at:

RE: $(sort) - what is lexical order? (was RE: Follow-up)

Putting OP's reply on the record. From: Rob Holbert [mailto:robholb...@gmail.com] Sent: Tuesday, July 19, 2011 04:49 To: Martin Dorey Subject: Re: $(sort) - what is lexical order? (was RE: Follow-up) Wow, Just putting your sources in order yourself will be much

RE: $(sort) - what is lexical order? (was RE: Follow-up)

of LC_COLLATE's value. @cindex removing duplicate words @cindex duplicate words, removing -Original Message- From: David Boyce [mailto:david.s.bo...@gmail.com] Sent: Tuesday, July 19, 2011 12:09 To: psm...@gnu.org Cc: Martin Dorey; robholb...@gmail.com; Bug-make@gnu.org Subject: Re: $(sort

RE: $(sort) - what is lexical order? (was RE: Follow-up)

:=$(call strcoll,B a)'; } | make -f - -p 21 | grep '^L ' L := a B martind@whitewater:~$ From: Rob Holbert [mailto:robholb...@gmail.com] Sent: Sunday, July 17, 2011 10:13 To: Martin Dorey Subject: Re: $(sort) - what is lexical order? (was RE: Follow-up) I contend

$(sort) - what is lexical order? (was RE: Follow-up)

OP has something of a point: contrast the locale-dependent behavior of sort(1) with make's $(sort): $ echo 'L:=$(sort B a)' | make -f - -p 21 | grep '^L ' L := B a $ { echo B; echo a; } | sort a B $ { echo B; echo a; } | LC_ALL=C sort B a $ I present this more to provoke we can't change that!

RE: [bug #33134] spurious error when stdout is already closed

maybe there's a better way of checking for closure than ftell http://software.jessies.org/svn/salma-hayek/trunk/native/all/ruby-launcher/ruby-launcher.cpp suggests: // This might look obscure but the man page suggests that it's a POSIX-compliant way // of testing whether a file

[bug #32247] ../make/main.c:534: error: static declaration of ‘bsd_signal’ follows non-static declaration

URL: http://savannah.gnu.org/bugs/?32247 Summary: ../make/main.c:534: error: static declaration of ‘bsd_signal’ follows non-static declaration Project: make Submitted by: mdorey Submitted on: Tue 25 Jan 2011 09:20:18 PM GMT

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #8, bug #31361 (project make): If your bug isn't in make, then it doesn't belong in make's bug database, under any name. ___ Reply to this item at: http://savannah.gnu.org/bugs/?31361

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #11, bug #31361 (project make): I just thought a more appropriate name might help others in my position And it might well do. (I too can't see how to change the name.) I just feared that you were hoping that someone would look at a gcc issue here. could you point me

RE: source file extension

define assert $(call assert,$($ARGS), The variable $ARGS is null) endef This code is dead - nothing calls it. I see that it includes an expression that will be evaluated (if it's ever called) as $(A)RGS when it was probably intended to say $(ARGS). SRCS = $(wordlist 2, 999, $(ARGS)) What

Re: Installing GoogleEarth

You typed a space instead of a hyphen after make. sudo make-googleearth-package --force sudo make googleearth-package --force Don't blush. If only all bug reports were so complete. From: bug-make-bounces+mdorey=bluearc@gnu.org

[bug #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

Follow-up Comment #2, bug #30105 (project make): So ifeq (yes, yes) counts a a blank line because it evaluates to nothing? a blank line would be consistent with next line that does not begin with a TAB, so that wording's not optimal. next line that begins with something other than a TAB might

[bug #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

Follow-up Comment #4, bug #30105 (project make): (That explanation is clear, thanks. That'll teach me to search for TAB in capitals, as is used sometimes elsewhere in the manual.) ___ Reply to this item at:

RE: Shorter and less error-prone rule for automatic prerequisite generation in the GNU Make manual

If an update to new source code, that would compile just fine in a clean checkout, breaks the incremental build, the build system is errornuous. I would like to agree with you, but this constraint is, in general, incompatible with incremental building That's a entertainingly provocative

Re: Bug

That isn't a problem with a makefile. That's a problem with main.cpp. I might guess that you should try changing iostream.h to iostream but that's only a guess out of goodwill. This mailing list isn't for helping with C++ problems. I don't know where you can turn for help. Perhaps wherever you

RE: Static multiple target rules

instead of a touch-file, use a tar-file ! Yeah, one of my company's makefiles uses a similar intermediate file to good effect. We've been using the touch-file or sentinel solution elsewhere for years. I'd previously suggested replacing the sentinels with tar files so we could get rid of all

RE: Make manual update

What's the most recent edition; @set EDITION 0.70 @set RCSID $Id: make.texi,v 1.64 2009/11/12 16:42:36 bosk Exp $ where can I find an authoritative copy ? http://cvs.savannah.gnu.org/viewvc/make/doc/make.texi?revision=HEADroot=makeview=markup Instructions for setting up a Cvs work area are

RE: Weird text-dependent bug in $(eval ...), simple test case

(b) the messages are only produced for some words That's not the case for me, with Debian Lenny's 3.81. mart...@whitewater:~/tmp$ dpkg -S `which make` make: /usr/bin/make mart...@whitewater:~/tmp$ dpkg --status make ... Version: 3.81-5 ... mart...@whitewater:~/tmp$ make -f buggyMakefile

debian/stamp/build/kernel) Fehler2

Perhaps the 2 corresponds to ENOENT, which means that a name wasn't found in a directory. mart...@whitewater:~/work/tiger$ sgrep ENOENT /usr/include/asm-generic /usr/include/asm-generic/errno-base.h:5:#define ENOENT2/* No such file or directory */

RE: not a bug but some strange behaviour

, 2009 14:27 To: Martin Dorey Cc: bug-make Subject: Re: not a bug but some strange behaviour $cat make.bat set PATH=cygwin_Path;oldPath make %* $ cat /tmp/Makefile export TEST_FLAG=test SHELL=/bin/bash test : tab printf $${TEST_FLAG}\n test2 : tab printf ${TEST_FLAG}\n test3

Re: issue when using MAKEFILES variable

and, while I can attest that it's tedious work, it rarely takes longer than, say, an hour. - Original Message - From: jean-luc malet jeanluc.ma...@gmail.com To: Martin Dorey Cc: bug-make@gnu.org bug-make@gnu.org Sent: Sat Oct 31 12:24:45 2009 Subject: Re: issue when using MAKEFILES variable

RE: [bug #27809] several win64 fixes

why can't you get rid of the cast altogether Because there is no implicit conversion from pointer to integer. users of MinGW will then complain about compiler warnings, right? Because of an implicit conversion from unsigned int (the definition of uintptr_t on w32) to long, on a platform where

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #3, bug #27437 (project make): Neither makefile.am nor Makefile.in are usually makefiles. makefile.am is, as I understand it from eg the first google match for that file's name, used to generate Makefile.in. Makefile.in is used, as I understand it from eg the second google

<    1   2   3   >