[bug #44853] gmake: execvp: bash: The parameter or environment lists are too long.

Follow-up Comment #2, bug #44853 (project make): Given that you already have GNU make 4.1, any chance you can use the new $(file ...) function (http://www.gnu.org/software/make/manual/make.html#File-Function) to do the same thing in your own recipe? It could be a path of much less resistance.

Re: [bug #46242] Race condition when input file is updated while compiling

On Wed, Oct 21, 2015 at 1:01 AM, Egmont Koblinger wrote: > Is there any realistic ETA on this feature? I think you’re missing the fact that nobody is actually working on these things. Make is an open-source project and not one of the ones that has direct corporate backing or

Re: [bug #46242] Race condition when input file is updated while compiling

On Tue, Oct 20, 2015 at 2:07 PM, Mike Shal wrote: > I would clarify that the benefit from using the technique in that article is > really because the rebuild algorithm is essentially changed from: > > if timestamp(foo.o) < timestamp(foo.c) {rebuild foo.o} > > to: > > if

Re: [bug #46242] Race condition when input file is updated while compiling

to put effort into getting that working than doing more work on the timestamp implementation. Note that there are published mechanisms for using checksums with existing make. For instance http://www.cmcrossroads.com/article/rebuilding-when-files-checksum-changes. David Boyce On Tue, Oct 20, 2015

Re: Macro question

tand how you can be capturing error messages with > redirection, unless link.exe is dumb enough to send errors to stdout. And (2) the second and third macro lines could be a little more robust by using $(basename $1) rather than assuming the extensions to be .dll and .lib. -David Boyce On Wed,

Re: Parallel builds across makefiles

home directories are NFS mounted) The > total elapsed time for the “-Otarget” run was then 6 hours. This is enough > of a reduction to be a little suspicious, but not much more. > > > > I ran with strace for both the “none” case and the “target” case. The > summaries are att

Re: Parallel builds across makefiles

3194 4 13780850 4946 read > > 0.04 21.309529 3 8034030 14388 close > > > > > > I am happy to run with any other settings that anyone might suggest since > I have the environment that is demonstrating the behavior. > > > > *Fro

Re: Parallel builds across makefiles

A couple of suggestions: 1. Check your value of TMPDIR if any. All -O is doing is redirecting output into a temp file and dumping it later. Effectively it turns command "foo" into "foo > $TMPDIR/blah; cat $TMPDIR/blah; unlink $TMPDIR/blah". This is why it seems almost impossible for it to slow

Re: Parallel builds across makefiles

I still think there must be an answer at the system-call level, i.e. using strace. It seems certain to me that some system call is taking much longer and that finding it would point to the solution. The fact that strace hasn't shown it yet implies that it's losing the thread at some point. Maybe

Re: exported vs command line variables

; wrote: > On Fri, Sep 23, 2016 at 11:23 AM, Paul Smith <psm...@gnu.org> wrote: > > On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote: > >> I still think that's a good plan, except that now I find out it ends > >> up exporting anyway. I'm sure it's too late to chang

Re: exported vs command line variables

Changing the subject a bit, I was unpleasantly surprised to learn while following this discussion that "Except by explicit request, make exports a variable only if it is either defined in the environment initially _or set on the command line_". For years I've noticed a tendency for users to mark

[bug #49661] syntax anomaly with order-only prereqs and pattern rules

Follow-up Comment #2, bug #49661 (project make): Ah, that makes sense. I was submitting this for someone else and should have paid closer attention. Thanks. ___ Reply to this item at:

[bug #49661] syntax anomaly with order-only prereqs and pattern rules

URL: Summary: syntax anomaly with order-only prereqs and pattern rules Project: make Submitted by: boyski Submitted on: Mon 21 Nov 2016 02:33:07 PM GMT Severity: 3 - Normal

Re: [bug #51237] Deadlock in Ctrl-C handler on Windows

> right before we do something that might "take a long time". Or "right before we do something that could change disk state". On Mon, Jul 10, 2017 at 11:29 AM, Paul D. Smith wrote: > Follow-up Comment #6, bug #51237 (project make): > > It's not the exact same problem

Re: [bug #51495] Notice when a rule changed, so target needs rebuilding

Someone needs to point out that this is entirely solvable within gnu make. Many recipes have been published; one is at https://www.cmcrossroads.com/article/rebuilding-when-cppflags-changes. The Linux kernel makefile structure has a nice implementation of this too. It might still be preferable for

[bug #16372] .DELETE_ON_ERROR does not delete directories

Follow-up Comment #2, bug #16372 (project make): Wow, this is really old. But I also cannot see any reason not to delete an explicitly named target regardless of whether it's a regular file or directory. ___ Reply to this item at:

Re: Are prerequisites made in deterministic order when parallelism is disabled?

I've been waiting for Paul to show up with the definitive word but he may be away. I'm 95% sure he's spoken on this before with the gist of it being "While not required by standard, GNU make has always worked left-to-right and this will not change". While I *think* I've correctly channeled his

Re: Unlink failure on abort

In the event this patch is used: I think the interleaved-ifdef style is hard to read and best avoided. How about either separating the Windows and "other" clauses at the top level or something like this (with suitable comment): + for (e = 0; e < 10; ++e) +{ + status = unlink

[bug #52076] wildcard/glob should be sorted

Follow-up Comment #6, bug #52076 (project make): Since make has used git for some years now I'd think "git bisect" or "git blame" or similar would be the way to find the commit. ___ Reply to this item at:

[bug #52076] wildcard/glob should be sorted

Follow-up Comment #8, bug #52076 (project make): Sorry, missed that. ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #52076] wildcard/glob should be sorted

Follow-up Comment #3, bug #52076 (project make): I think you're wasting time re-litigating this. It's not a bug, it was a deliberate, documented change from a while ago. The odds of getting it changed back are low, and even if that happened it would be a long time before a release with the change

accessing $@ internally to make

anyone know make internals well enough to tell me where and how to get access to $@ just after the recipe has finished? I'm thinking of experimenting with an enhancement locally but could submit it as a new feature if desired. Thanks, David Boyce ___ Bug

showing lines actually parsed

I've been wondering how hard it would be to add a "--debug=l (lines)" (or maybe "p/parsed or s/serialize") option to "straighten out" conditionals by printing only the lines actually parsed. The effect would be to take a potentially very complex makefile suite with many includes and conditional

question about autotools within GNU make itself

This isn't a bug in GNU make at all, just a question about how it interacts with its own use of automake which is something I have little experience of. First, a little background. I'm working in a corporate Linux environment in which there are a few tasks that don't work well in NFS so I've moved

[bug #52912] minor bug in GNU make's own Makefile under .ONESHELL

Follow-up Comment #4, bug #52912 (project make): Yes, I understand you weren't suggesting the fake "bash" be on PATH. But I still think it's an unfortunate hack. I've been using the build of make itself as a test/demo for a related build tool I'm working on. I'm under no illusion that the rest

[bug #52912] minor bug in GNU make's own Makefile under .ONESHELL

Follow-up Comment #2, bug #52912 (project make): Hmm. When you say "I think that your use-case is going to cause lots of other problems", I'm not sure whether you're referring to the make build model per se or the greater universe of makefiles. I'm aware that .ONESHELL has certain pitfalls in the

[bug #52912] minor bug in GNU make's own Makefile under .ONESHELL

URL: Summary: minor bug in GNU make's own Makefile under .ONESHELL Project: make Submitted by: boyski Submitted on: Tue 16 Jan 2018 02:12:06 PM UTC Severity: 3 - Normal

MAKEFLAGS and -j in recursion

I'm aware that the behavior of MAKEFLAGS wrt -j is a little unusual, however I was still surprised by the result of the following simulation of a recursive make with -j and haven't found anything in the manual to support it: % cat Makefile level ?= 0 $(info At level $(level)

[bug #53201] Target runs incorrect command when shebang line exceeds kernel limit

Follow-up Comment #3, bug #53201 (project make): Sorry, I was thinking of a different kernel limit but my second observation, that the difference observed has to do with fast path optimization, remains. Working around it by setting SHELL=//bin/sh in the makefile is probably safer than .ONESHELL.

[bug #53201] Target runs incorrect command when shebang line exceeds kernel limit

Follow-up Comment #1, bug #53201 (project make): I think a couple of facts here may need correcting though the issue is quite real. I suspect you are not running into a kernel limit since modern Linux kernels have no such limit (at one time the limit was 131K, then doubled to 262K, then removed

Re: Case-insensitive targets

Going way back upstream to the original test makefile: - default: program_name PROGRAM_NAME Program_Name program_name: @echo 'Do something for $@.' - The thing is that these targets are not actually declared as phony so of course they're treated as files. I'm surprised no one

[bug #54630] "obsolete" language too strong

URL: Summary: "obsolete" language too strong Project: make Submitted by: boyski Submitted on: Fri 07 Sep 2018 03:14:01 PM UTC Severity: 3 - Normal Item Group:

[bug #54816] $(wildcard ...) function does not report dangling symlinks

URL: Summary: $(wildcard ...) function does not report dangling symlinks Project: make Submitted by: boyski Submitted on: Wed 10 Oct 2018 01:32:48 PM UTC Severity: 3 - Normal

[bug #54740] .SILENT: propagates into recursive makes

URL: Summary: .SILENT: propagates into recursive makes Project: make Submitted by: boyski Submitted on: Thu 27 Sep 2018 03:32:36 AM UTC Severity: 3 - Normal Item Group:

Re: [bug #54675] avoid redundant recipe warning for identical recipes

o all the recipes. It's not > ideal but it works. > > -brian > On Mon, Sep 17, 2018 at 7:23 PM David Boyce > wrote: > > > > URL: > > <https://savannah.gnu.org/bugs/?54675> > > > > Summary: avoid redundant recipe warning for iden

Re: [bug #55243] Request for a way to indicate that the same recipe execution produces several targets

of this, which was being rewritten when I had to abandon it, but the client worked pretty well when I dropped it. Close to dead but mentioned for completeness. David Boyce On Fri, Dec 28, 2018 at 5:36 PM Brian Vandenberg wrote: > > blah.h : blah.cc >> >> no real recipe was pro

[bug #54675] avoid redundant recipe warning for identical recipes

URL: Summary: avoid redundant recipe warning for identical recipes Project: make Submitted by: boyski Submitted on: Tue 18 Sep 2018 01:23:09 AM UTC Severity: 3 - Normal

[bug #54676] no way to query current vpath value

URL: Summary: no way to query current vpath value Project: make Submitted by: boyski Submitted on: Tue 18 Sep 2018 01:32:16 AM UTC Severity: 3 - Normal Item Group:

losing cached no-such-file messages from includes

I encountered a surprising corner case recently; not clear whether it constitutes a bug. The documentation is clear that when an include file is not found make sits on the message for a while in case the file can be made. That I understand, but there are two surprising behaviors which result.

Re: Idea: Enable .ONESHELL to be per-target

> You can probably make a case for either one, but .ONESHELL already exists, so let's just expand what's already there. It's also worth noting that .ONESHELL is a recommendation from POSIX. There's a note in POSIX.2 that says something along the lines of "Recipes should have been passed to a

Re: Idea: Add command-line option for reporting potential makefile errors

In this context it might be worth mentioning two projects of mine, one simple/lightweight and the other complex and semi-abandoned. I will not describe them here in detail because the links do so. 1. Poor Man's File Auditor (https://github.com/boyski/pmaudit) This is a lightweight, unambitious,

[bug #56484] [RFE] compile modified files first

Follow-up Comment #1, bug #56484 (project make): I don't think this could be an opt-out because make has a very longstanding expectation that prerequisites are built in left-to-right order (with -j1). ___ Reply to this item at:

Re: Feature request / patch: dependency-only prerequisites

I also think the proposal is reasonable but I think it would be "stickier", i.e. less likely to get lost, if you filed it as an enhancement request via the Savannah bug reporting system. On Tue, Jul 9, 2019 at 5:27 AM Tim Murphy wrote: > I quite like this idea because so many of us work on

Re: [bug #56701] Do not allow -j without a number

My vote is to leave -j alone. Everyone knows it shouldn't be used that way in production, especially on shared host, but I've been known to use -j alone when testing out the parallel-safety of a makefile or in various other ad-hoc test scenarios. I could even imagine it being used deliberately as

Re: GNU make 4.2.90 release candidate available

Feedback on release notes - there are a couple of things unclear at least to me: > the -l/--load-average option will use the contents of that file to determine how many jobs are running at any given instant, and compare that value to the load value requested. Compare and do what? This doesn't

Re: GNU make 4.2.90 release candidate available

em will do so at compile time. I think this could be clarified. In all of these the main point is for the release text to be as clear as possible; it's not about explaining it to me. As long as you're satisfied it's clear I'm happy to let it go. On Mon, Aug 26, 2019 at 11:08 AM Paul Smith wrote:

wildcard ignores dangling symlinks, and .MAKEPID

These are two minor topics and I'm not asking for anything to be done about either for the upcoming release but I thought it couldn't hurt to mention them for discussion. First, the $(wildcard ...) function appears to rely on stat(), not lstat(), which means it considers a dangling symlink to not

[bug #56892] toxic combination of -include and match-anything rules

Follow-up Comment #2, bug #56892 (project make): Ok. WRT your second point, you are of course right and I didn't think it out properly. WRT the delayed warning being new as of 4.2.1, I didn't know that and agree that it's a serious compatibility issue, so I'm happy to drop this.

[bug #56892] toxic combination of -include and match-anything rules

URL: Summary: toxic combination of -include and match-anything rules Project: make Submitted by: boyski Submitted on: Sat 14 Sep 2019 08:28:32 PM UTC Severity: 3 - Normal

Re: Feature request / patch: dependency-only prerequisites

um 15:42 schrieb David Boyce: > > I also think the proposal is reasonable but I think it would be > "stickier", i.e. less likely to get lost, if you filed it as an enhancement > request via the Savannah bug reporting system. > > I'd be glad to do that if it increases

INSTALL misdirection

I know the INSTALL file is missing from 4.3 so I can't check it directly, so while building a new copy of 4.3 from source I relied on the version from 4.2.1. It says: 1. `cd' to the directory containing the package's source code and type `./configure' to configure the package for your

[bug #59169] Add a --debug=why category for the -d/--debug option

Follow-up Comment #2, bug #59169 (project make): I've posted a patch to do this. Very lightly tested but after all it doesn't add or change any functionality. ___ Reply to this item at:

[bug #59169] Add a --debug=why category for the -d/--debug option

Additional Item Attachment, bug #59169 (project make): File name: debug_print_why.patch Size:2 KB ___ Reply to this item at:

[bug #59169] Add a --debug=why category for the -d/--debug option

URL: Summary: Add a --debug=why category for the -d/--debug option Project: make Submitted by: boyski Submitted on: Wed 23 Sep 2020 02:22:35 AM UTC Severity: 3 - Normal

[bug #59169] Add a --debug=why category for the -d/--debug option

Follow-up Comment #3, bug #59169 (project make): I've updated the patch a bit to coalesce message style. The current --trace output comes in one of two formats: Makefile:12: target 'foobar' does not exist Makefile:15: update target 'hello.o' due to: hello.c According to whether there's a valid

simple assignment of target-specific variables

I'm not saying this should be considered a bug but it's at least an "interesting result". I've always followed the rule of thumb that simple (:=) assignment should be used when the RHS contains $(shell ), and this is still a good mnemonic 99.9% of the time, but I've run across a case where it

Re: simple assignment of target-specific variables

es the variable is expanded, it's a boolean thing: the target is built or not built, the target-specific variable is needed or not. David On Tue, Jun 9, 2020 at 8:52 AM Dmitry Goncharov via Bug reports and discussion for GNU make wrote: > On Tue, Jun 9, 2020 at 9:10 AM David Boyce wrote: >

Re: simple assignment of target-specific variables

Yes, that's the suggestion I was making though I don't know the innards of make well enough to know how hard it would be. David On Tue, Jun 9, 2020 at 9:21 AM Dmitry Goncharov wrote: > On Tue, Jun 9, 2020 at 12:01 PM David Boyce > wrote: > > When I say "needed" he

[bug #59169] Add a --debug=why category for the -d/--debug option

Follow-up Comment #5, bug #59169 (project make): I'd consider this change too small to require attribution so not to worry! ___ Reply to this item at:

Re: [bug #60538] Environment variable overrides explicit assignment

Most likely he thinks/thought that since there are two different make processes with a python process in between the command line override wouldn't leak to the child make. But (from the manual): > Likewise variables defined on the command line are passed to the sub-make through MAKEFLAGS. (5.7.3)

Re: gmake and ccache conspiring together in creating gremlins

> The program could read this -1 to (for example) uint16_t and interpret as 65535 and fail to notice the parent is not giving any fd. File descriptors have been of int type since Unix was designed (at least) and -1 is documented as the invalid descriptor. E.g. the open() system call and every

Re: Parallel job instance identifiers?

> One possibility would be for make to write out bytes with values 0,1,2,3... then when it gets to 255 start over again ... I hope this sin't a dumb question, I've never worked with the job server, but hy not use the value of the file descriptor from the parent side as the token to send down the

Re: Parallel job instance identifiers?

Wait, it is a dumb question. Never mind. David On Mon, Sep 6, 2021 at 7:58 AM David Boyce wrote: > > One possibility would be for make to write out bytes with values > 0,1,2,3... then when it gets to 255 start over again ... > > I hope this sin't a dumb question, I've never work

[bug #61328] elide the distinction between "dir" and "dir/"

Follow-up Comment #5, bug #61328 (project make): > Why is this a concern? I may have phrased it wrong. I just meant to bring up "a question that might reasonably be raised" and rebut it in advance. > Unlike other tools make doesn't really care if a prerequisite is a file or a directory. My

[bug #61328] elide the distinction between "dir" and "dir/"

URL: Summary: elide the distinction between "dir" and "dir/" Project: make Submitted by: boyski Submitted on: Sun 10 Oct 2021 11:01:25 PM UTC Severity: 3 - Normal Item

[bug #61328] elide the distinction between "dir" and "dir/"

Follow-up Comment #7, bug #61328 (project make): I don't think I said exactly "directories should only/always be order-only" (so it shouldn't be in quotes), but I do think the value of this enhancement would be primarily in order-only directory creation logic. However, if you envision it as being

[bug #61328] elide the distinction between "dir" and "dir/"

Follow-up Comment #2, bug #61328 (project make): > Do you mean that make assumes that any order-only prerequisite is a directory and compares 'foo' as equal to 'foo/', as long as 'foo' is order-only? That's backward. Make should not assume O-O prereqs are directories; my argument is that it can

Re: [bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

> The only thing that is guaranteed to work is to always create the children processes with a NULL environment ... This has been stated twice as an absolute fact but it leaves an obvious question: why can't GNU make dig up these special "=" env vars on its own and add them to its custom "envp"

Re: -V, --verbose, as opposite of -s, --silent, --quiet

BTW we use a slightly different and, I think, slightly improved version of what's shown there (see below). Improvements are: 1. Either the verbose or the concise output is shown, vs both in verbose mode as the original does. 2. It uses $(info ...) instead of echo which saves a fork/exec per

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

Wouldn’t a less intrusive solution be to check the inode/device of stdout and if it’s the same as that of /dev/null just forego locking? > On Jul 24, 2021, at 11:26 AM, Eli Zaretskii wrote: > > Follow-up Comment #5, bug #60774 (project make): > > The MS-Windows port of GNU Make doesn't lock

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

> That would help this specific case indeed... The point is that only /dev/null *should* be shared. Any other file *might* be locked by an unrelated process but that would represent an error condition in which incorrect results should be expected. I can’t think of a file other than /dev/null

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

Paul, I don't understand why you say "I don't know of any portable way of determining whether stdout is going to /dev/null, or not" and "However, it's moot because I don't think we can detect it". It's simple to detect this on a Unix-like host (see sample script below) and my contention is that

[bug #54676] no way to query current vpath value

Follow-up Comment #1, bug #54676 (project make): Actually I think "vpath %.c ?" might be fine. Technically incompatible but the odds of anyone having ever used a directory called "?" seem very low. ___ Reply to this item at:

[bug #62232] could targetshave an implicit order-only dependency on their parent directory?

URL: Summary: could targetshave an implicit order-only dependency on their parent directory? Project: make Submitted by: boyski Submitted on: Tue 29 Mar 2022 01:37:57 PM UTC

Re: GNU make troubleshooting

A few thoughts, mostly on the shell/recipe end of things: - I find it interesting that there's no mention of -n which seems like a bog-standard, POSIX-compliant, debugging method. It's also another way of getting around @. Simplistic but worth mentioning IMHO. - I wonder why there's so much

Re: Goodbye to GNU make's "build.sh" ... ?

The obvious end-point of #2 is to add a make-4.3.tar.gz file to future make packages and modify build.sh to unpack and use it. This might involve renaming the "inner" script to "build-4.3.sh" or similar. But I also have the same question: what are the real-world cases where build.sh is needed?

[bug #62397] jobserver unavailable from $(shell $(MAKE)...)

Follow-up Comment #1, bug #62397 (project make): Could you also work around it with: makeprog := $(MAKE) OUTPUT := $(shell env | grep MAKEFLAGS 1>&2; $(makeprog) -f 3.make) ___ Reply to this item at:

Re: GNU make 4.3.90 release candidate available

didate available > > ***** EXTERNAL EMAIL * > > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Mon, 26 Sep 2022 12:31:34 -0400 > > > > On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > > > BTW wget complain

Re: GNU make 4.3.92 on mingw

I'd think it would be easy to write a diff script in Perl to avoid platform dependencies. In fact the result would be simpler than Paul describes because instead of actually modifying logfiles the mods could be done in-memory by the script. Reading in two text files, strinpping off newlines,

Re: GNU make 4.3.90 release candidate available

modified in a makefile, it will be re-parsed > immediately rather than after all makefiles have been read. Note that > although all options are parsed immediately, some special effects won't > appear until after all makefiles are read. > > * The -I option accepts an argument &quo

Re: shell function: confusing error when shebang incorrect

I have a feeling I may be treading over old ground here but wouldn't a simple solution be to simply abandon fast-path for explicit $(shell ...) invocations? After all, as Kirill says: > The documentation of the `shell` function pretty directly states that it will launch the shell, no exceptions,

[bug #63686] implement a flag to promote make warnings to fatal errors

Triage Status: None ___ Follow-up Comments: --- Date: Fri 20 Jan 2023 09:12:57 PM UTC By: David Boyce GCC has a -Werror option causing warnings to be promoted to fatal errors which I (

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #1, bug #63686 (project make): If this was going to be implemented, I suggest doing it as a special target e.g. .WERROR: which would allow maximum flexibility. A proprietary build system could embed this in their makefiles, and for open-source projects or other cases where it

[bug #63693] allow a way of asserting that $(SHELL) is POSIX/Bourne compatible

: None Triage Status: None ___ Follow-up Comments: --- Date: Mon 23 Jan 2023 09:20:06 PM UTC By: David Boyce Currently, make decides whether the current shell is sufficiently POSIX-shel

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #5, bug #63686 (project make): Sorry, previous comment should read "I cannot think of an reason to prefer ...". ___ Reply to this item at:

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #13, bug #63686 (project make): Hmm, this is a dizzying array of choices! Since 4.4.1 is gone and this feature will only be in the next full release which is presumably far off still, it seems there's no rush to decide. Maybe push it as is to let people play with it in beta

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #7, bug #63686 (project make): It almost sounds like you're making the case against your own proposal now :-). Given what you say, what's the reasoning for doing this as a --warn... flag vs a special target? I trust your judgment but I don't quite understand it.

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #10, bug #63686 (project make): Again, I'm generally ok with your implementation. No big objections, but in an attempt to carry these discussions to closure: > MAKEFLAGS are by definition passed to recursive makes ... My $dayjob builds, among other things, a Linux kernel

Re: wildcard and globstar

This raises a side question: it's quite common for glob libraries to support ** as meaning "search recursively", such as https://docs.python.org/3/library/glob.html. I'd be a bit surprised if gnulib's glob implementation didn't support this. Is it possible for GNU make to support $(wildcard

Re: MAKEFLAGS=-r

Everything else aside, there's a profound difference between MAKEFLAGS=-r and MAKEFLAGS+=-r. The latter is far less destabilizing. And yes, GNUMAKEFLAGS is definitely better for this use. On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > Dmitry Goncharov wrote: > > Once the makefile author

Re: MAKEFLAGS=-r

NOP in non-GNU makes anyway. Except that it would take effect in recursive invocations but that complicates things further. Anyway, I really should stop talking since I know zero about automake. David On Mon, Jul 17, 2023 at 11:22 AM Bruno Haible wrote: > David Boyce wrote: > > Ev

Re: GNU make troubleshooting

Minor side point: the "tail +7" option is deprecated by POSIX, replaced by "tail -n+7". Official GNU documentation should preferably follow POSIX. David On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > Dmitry Goncharov wrote: > > > 1) The title, and what does the user want? > > This patch

Re: new feature idea: ingesting processed rulesets

> DIR := $(shell pwd) My only contribution to this is to point out that I believe the above construct, while very common, is unnecessary. The $(CURDIR) variable is defined by the manual to be an absolute path to the current working directory of the make process. Combined with the fact that make

<    1   2