Re: library of make fragments

> On Apr 5, 2025, at 11:43 AM, Joshua DeWeese wrote: > > Hi, > I was wondering about the possibility of adding, as a feature to make, > the addition of a standard makefile fragments library. On a related note, I released a library called "make-booster": https://github

Re: Ability to print the make database as json - experimental

amp; asking to get it added. I, for one, am unlikely to use it unless it's in the mainline "make" - but I'd be a happy user if it's in there. -- David A. Wheeler

Re: Ability to print the make database as json - experimental

akefile database in JSON format. There are many tools that can pretty-print JSON once you have it. So if formatting the JSON is hard, I suggest not focusing on it. Let other tools that focus on that job do it. --- David A. Wheeler

Re: Reporting Security Violations in Software Package

so not a security violation: ... I don't see the security violation either. Generally GNU make doesn't have elevated privileges in the first place. If one is identified I'd like to know! --- David A. Wheeler

Re: [RFC PATCH v4 0/3] per-target .ONESHELL with shard recipe fix

ms exactly correct. ".ONESHELL", applied to a specific target, should *only* apply to that target and not to anything else it calls. It's only a property of that specific target. Thanks! --- David A. Wheeler

Re: [RFC PATCH v3 0/1] per-target .ONESHELL support

and documentation. I think this is great functionality! Thank you! I also think it'd be nice to support: foo: .ONESHELL in *addition* to: .ONESHELL: foo So that you don't need to have additional lines to make such settings. But that's a *different* issue. --- David A. Wheeler

Idea: Allow some special targets to also be given as prerequisites (foo: .PHONY == .PHONY: foo)

~ foo: echo > foo .PHONY: foo I propose also allowing: foo: .PHONY echo > foo Examples where this might be useful: .PHONY, .PRECIOUS, .INTERMEDIATE, .NOTINTERMEDIATE, .SECONDARY, .IGNORE, .SILENT, .NOTPARALLEL, .ONESHELL Thoughts? --- David A. Wheeler

[bug #64571] Add option to print targets

Follow-up Comment #16, bug#64571 (group make): I think it's important to identify "what is the use case" before adding options. I think there are two different use cases that are getting conflated. I suggest supporting two different options for the two cases. 1. "Give me the list of targets of th

Re: new feature idea: ingesting processed rulesets

$(CURDIR) is even better, since then you don't have to remember to insert it in each makefile fragment. So that sounds like the "obvious" solution unless there's something I'm missing. --- David A. Wheeler

Re: new feature idea: ingesting processed rulesets

an *only* see the dependencies of a subdirectory, I think you're optimizing the wrong problem. Make is *very* fast at parsing makefiles & at checking file timestamps. But if you give Make the wrong data, it will do the wrong thing. You may then try to "fix" it by overspecifyi

Re: new feature idea: ingesting processed rulesets

" invoke other "make" processes (aka "recursive make"), automake (part of the autotools) has support for it using "SUBDIRS=". It is a convenient noose, but I recommend not putting your head in it :-). I feel like there's some miscommunication that I can't quite identify. But in spite of that, I hope I answered your question. --- David A. Wheeler

Re: new feature idea: ingesting processed rulesets

> > On Tue, 23 May 2023 12:07:51 -0400 > "David A. Wheeler" wrote: >> The solution is to *NOT* use recursive make. Have *ONE* process run the >> makefile, with the correct data. Now you can enable parallel jobs, and have >> it run really quickly, bec

Re: new feature idea: ingesting processed rulesets

nd. You don't need to rig make to work with a bad design; change the design. --- David A. Wheeler

Re: Handling references to invalid variables

The question is, should this notification be a warning? Or should it > be a fatal error? Definitely start by making it a warning. I have no idea how common they are, but they're probably more common than we'd like, so people will need time to fix the problems it reveals. --- David A. Wheeler

Re: FreeBSD 13.1-RELEASE $< and $^

d. IIRC, on FreeBSD, "make" is BSD make and "gmake" is GNU make. --- David A. Wheeler

Re: [SCM] make branch, master, updated. 4.3-234-gf6ea899d

ess reliable way", and "compared to" instead of "than", leaving the sentence as: Because of this, @code{.WAIT} is an less reliable way to impose ordering compared to defining a prerequisite relationship. --- David A. Wheeler

Re: False positive "doesn't match the target pattern" error

> On Aug 22, 2022, at 12:02 AM, Alejandro Colomar > wrote: > > Hi David, > > On 8/22/22 04:45, David A. Wheeler wrote: >>> On Aug 20, 2022, at 11:35 AM, Alejandro Colomar >>> wrote: >>> I'd say there is: make(1) treats file names as tex

Re: False positive "doesn't match the target pattern" error

less common to have directories as prerequisites or targets, so not handling them with special conveniences seems quite reasonable. --- David A. Wheeler

Idea: Add landlock support where present

x27;d be nontrivial effort to integrate their changes upstream, but the developers might be willing to help if there's interest. If you want to detect makefile rule errors at run-time, you're also welcome to try out my "make-audit" tool: https://github.com/david-a-wheeler/make-au

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

ld using another existing "make" is an obvious way to do that. I'm not so picky on *how* to do that. --- David A. Wheeler

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

d is > not intended to be, user documentation. It's a reference page. I agree. But adding 1-2 sentences seems reasonable. --- David A. Wheeler

Re: GNU Make bug report: broken dry-run functionality with sub-make invocations

instance that is run. Also, be prepared for side effects of output redirection. (If someone has a better way to write that last sentence, please do so.) It's a pretty important exception, so it should be explicitly described in the summary. --- David A. Wheeler

Re: Idea of triggering bugs in users' Makefiles

en (its basename does not begin with "."). There would probably need to be some options to control what "should be listed as a dependency" beyond the default. If this was added to make, it's fine if the check doesn't run on all possible architectures. You can run the check on some widely-used system, and fix the makefile, and then run the makefile on anything else. Of course, someone would have to do the work :-). --- David A. Wheeler

Re: [bug #60798] Make does not compile with GCC 11.1.0

ilation problems. --- David A. Wheeler

Re: [bug] Sibling submakes: wait for other submakes before failing

ases than to use recursive makes. For more info, see “Recursive make considered harmful” by Peter Miller: https://web.archive.org/web/20200209034547/http://aegis.sourceforge.net/auug97.pdf --- David A. Wheeler

Re: gmake-4.2.90 regression (segmentation fault in sum_up_to_nul )

It is extremely dangerous to dereference outside and allocated range, and it really should never be done today. As you well know, in C that is undefined. However over the last few years the C compilers have been getting increasingly aggressive to implement optimizations that assume that no one w

[bug #56895] Cannot build make due to compiler warnings/failures

Follow-up Comment #4, bug #56895 (project make): Excellent, I will check it out (literally). Thank you! ___ Reply to this item at: ___ Message sent via

Re: [bug #56895] Cannot build make due to compiler warnings/failures

Ah, ok, I had assumed the fallthrough was intentional. Looks like the warning found a real bug. As far as the other changes go, dealing with them some other way would be great. I just needed to be able to compile the code. --- David A.Wheeler___ Bug-ma

Trivial fixes so "make" can compile on Cygwin

ially fixed; I've posted a patch here: https://savannah.gnu.org/bugs/index.php?56895 These are very trivial fixes. Please apply these or something like them to eliminate the warnings, thanks!! --- David A. Wheeler ___ Bug-make mailing list Bug-ma

[bug #56895] Cannot build make due to compiler warnings/failures

Additional Item Attachment, bug #56895 (project make): File name: ,trivial-compile-fixes Size:2 KB ___ Reply to this item at:

[bug #56895] Cannot build make due to compiler warnings/failures

URL: Summary: Cannot build make due to compiler warnings/failures Project: make Submitted by: dwheeler Submitted on: Sun 15 Sep 2019 03:32:15 AM UTC Severity: 3 - Normal

[bug #56749] Any chance to make new release?

Follow-up Comment #2, bug #56749 (project make): I agree. The new "&:" all by itself is worth a new release. Enabling clean compiles on common systems (at least Linux) would be a big improvement. I think having releases more often (say annually) would be better for all, as long as the releases di

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

nd make it. There's no conflict between this syntax proposal & adding more built-in functions. --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

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

before & after execution. That's extraordinarily portable (it even works on Cygwin) and FAR less fussy. It can't monitor lstat & friends, but I think that's okay. inotify can't notice lstats either, strace imposes a huge performance overhead, and LD_PRELOAD is fussy &

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

tionality is very basic "notice when the system tries to check or open a file". Many mechanisms use such services, not just this, and you'd think they'd have been sued by now. Thanks. --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: Idea: Standard way to negate special targets

pretty obvious that there are multiple possibilities, so they can look it up once & remember the answer from then on. Also, people can choose to list negations at the end of the list of prerequisites, and that style seems adequate: my-weird-target: foo bar ! .ONESHELL ! dont-want-to-depend-on-thi

Re: Idea: Standard way to negate special targets

fter it. For example: tricky_target: !.ONESHELL .PHONY ... There's some logic to it; the prerequisites are space-separated, and now they're still space-separated including the "not a prerequisite" statement. That would create pain for filenames that begin with "!",

Re: Idea: Standard way to negate special targets

David A. Wheeler (11 June 2019 22:25) wrote: >> I know of no other use for "!" in prerequisites. On June 12, 2019 4:42:15 AM EDT, Edward Welbourne wrote: >Well, it could be a file-name ;^> Fair enough, although I expect that to be extremely rare. That ca

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

#x27;s okay; I envision doing this checking occasionally, instead of doing it on every run. This might not be implemented on all platforms, but it would be useful on many platforms & help people fix their makefiles for all. --- David A. Wheeler ___

Re: Idea: Add .COMMANDCHANGE and .CACHE

ironment variables". > Again, I think what you really want is a key derived from all the recipes in > the entire dependency DAG of the target. I think this picks up the case > you're > considering here, plus others where significant side effects exist that aren't > exp

Re: Idea: .MUSTCREATE

On June 9, 2019 9:50:53 PM EDT, Paul Smith wrote: >On Sun, 2019-06-09 at 19:21 -0400, David A. Wheeler wrote: >> If I understand correctly, that means that a single: >> .WONTCREATE: >> will be enough to detect a problem if *all* my rules >> are supposed to always c

Idea: Standard way to negate special targets

inherited. If you call on something else, and it wants to disable a special target, then it has to do the same thing. I know of no other use for "!" in prerequisites. If that's not okay, perhaps ".NOT" would be a good alternative. --- David A. Wheeler ___

Idea: MAKE_SILENCEWARNINGS variable silences make warnings

does not print make warnings. Make errors are still printed, and commands (which can generate messages) are unaffected. It's expected that MAKE_SILENCEWARNINGS would typically be used as a target-specific or pattern-specific private special variable. E.g., weird-thing: MAKE_SILENCEWARNINGS = t

Idea: Automatically detect erroneous multi-targets

ng: Use &: (not :) or an intermediary target when modifying multiple targets: (target names) I don't know of any reason you'd want to silence warnings. If you did, I think that'd be a separate change (to be proposed separately). Sor

Re: Idea: Add .COMMANDCHANGE and .CACHE

> On Mon, 2019-06-10 at 13:14 -0400, David A. Wheeler wrote: > > Idea: Add .COMMANDCHANGE and .CACHE On Tue, 11 Jun 2019 11:06:51 -0400, Paul Smith wrote: > Unlike some of the other ideas I think this one needs a lot of thought > and consideration. To me it seems the most compl

Re: Idea: Add .COMMANDCHANGE and .CACHE

On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler wrote: > > Using a lot of some_fragment.mk files gets you *closer*, but it's not > > the same thing. My proposed .COMMANDCHANGE depends on > > the *expanded* set of commands, not the original commands. > > That wa

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

ines between parameters when the parameter set is long. It would also simplify passing arguments containing commas. I would be happy if all 3 were implemented, really; they all have their own trade-offs. At least #1 or #2 should be implemented. --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: Idea: Add .COMMANDCHANGE and .CACHE

hey want cached. That's nice functionality for what I expect will be relatively few lines of code. Sure, users can write code to cache things themselves, but I think getting that functionality with a single additional line in the Makefile is valuable. --- David A. Wheeler =

Re: Idea: Add .COMMANDCHANGE and .CACHE

un #2 the file x.c.mk has not changed, and x.o is still after x.c. Therefore, x.o will not be regenerated. If we add: .COMMANDCHANGE: then a change to CCFLAGS *will* cause re-execution of the rule that generates x.o. --- David A. Wheeler ___ Bu

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

> On Mon, Jun 10, 2019 at 4:56 AM David A. Wheeler > wrote: > > Another idea: Enable .ONESHELL to be per-target. On Mon, 10 Jun 2019 11:47:19 -0800, Britton Kerin wrote: > Strongly seconded, I would definitely use this. I've been > attracted to it many times but n

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

ully refine them. And of course, if someone *else* implements them that'd be even better from my point of view :-). --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: Idea: Add .COMMANDCHANGE and .CACHE

ting caches in make solves the problem *once* for *all* uses of make, instead of requiring every user to recreate it. (5) Make is in a very good spot to know what's going to be done. (6) The implementation will be trivial, probably ~20 lines of code plus the hashing function.

Idea: Add .COMMANDCHANGE and .CACHE

of the rule if there's no corresponding entry. Note that .TREEROOT still applies. I suspect .COMMANDCHANGE is a terrible name; better ones welcome. --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Idea: Enable .ONESHELL to be per-target

.ONESHELL ... ...commands that will run as a single shell --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Re: Idea: Allow $(name ...) as an abbrevation of $(call name ....)

7;s more likely to be an error than a function call. So perhaps the short form should require something other than a ")" right after the name's whitespace; if you want to call a function with no parameters (why?) you'd be required to use $(call NAME). I'd be happy with

Re: Idea: Automatically correct timestamps

ally when > compiler options have changed etc. Oh, I see. Okay, this proposal won't help with *that*. But I still think it'd be a good thing to do. Below is a revised proposal, given that feedback. --- David A. Wheeler == The following propos

Re: Idea: .MUSTCREATE

EATE: # By default fail if rule won't create its target # Don't fail when my_command fails to create weird-thing weird-thing: .WONTCREATE otherthing my_command --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Idea: Allow $(name ...) as an abbrevation of $(call name ....)

tice I don't think that's very useful. If you really wanted that (why?), I think $(call no-parameters) would be clearer as a call, and $(no-parameters) seems more useful :-). Okay, that's my final of 4 ideas (well, at least for the moment :-) ). --- David A. Wheeler ___

Idea: Allow certain special targets as dependencies

cant. It also eliminates a source of errors. I propose that this abbreviation with the following special targets: .PHONY .PRECIOUS .INTERMEDIATE .SECONDARY .IGNORE .SILENT .NOTPARALLEL .ONESHELL --- David A. Wheeler ___ Bug-make mailing list Bug-make@gn

Re: Idea: Automatically correct timestamps

pt into the behavior of automatically fixing timestamps, but at least the capability would be available. --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

Idea: Automatically correct timestamps

TTIMEADJUST is true { fail "target {target} has a time before its prerequisite {list} but its time cannot be adjusted" } } else { if MAKEMUSTTIMEADJUST is true { fail "target {target} has a time before its

Idea: .MUSTCREATE

can be escaped the usual way, namely "./.MUSTCREATE". This would only affect makefiles with .MUSTCREATE; it would not change the behavior of existing makefiles. --- David A. Wheeler ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

[bug #31430] Add support for the BSD "shell assignment" operator (!=)

Follow-up Comment #8, bug #31430 (project make): Thanks so much for adding the BSD shell assignment operator to GNU make!! I look forward to this and other improved-portability goodies (such as the new POSIX ::= assignment operator) in the next GNU make release.

[bug #31430] Add support for the BSD "shell assignment" operator (!=)

Follow-up Comment #3, bug #31430 (project make): I've updated the patch, so here is a new version of the patch: http://www.dwheeler.com/misc/shell-assignment.v2.patch This new "version 2" uses the func_shell routine instead of popen(), so it should work anywhere that $(shell ...) works. I also

[bug #31430] Add support for the BSD "shell assignment" operator (!=)

Follow-up Comment #2, bug #31430 (project make): Yes, please send me the paperwork, to dwheeler at dwheeler dot com. ___ Reply to this item at: ___ M