Re: library of make fragments

On Sun, Apr 6, 2025 at 8:28 AM Bahman Movaqar wrote: > > Hey all 👋️ > > Very interesting topic! > > I thought I'd share my own attempt at having a collection of useful utilities > for my Makefiles 😅️ Slightly more on the datastucture side there's the very nice-looking GNU Make Standard Library h

Re: order-only prerequisites themselves get rebuilt when not needed

On Wed, Mar 19, 2025 at 5:59 AM Dmitry Goncharov wrote: > > On Tue, Mar 18, 2025 at 8:06 AM Paul Smith wrote: > > I see from the patch: you don't mean "never" you mean, only if the > > prerequisite does not exist will it be updated. > > Right. > > > I agree this preserves probably the most common

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, Mar 17, 2025 at 4:12 AM Paul Smith wrote: > > On Sat, 2025-03-15 at 08:28 -0400, Dmitry Goncharov wrote: > > On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote: > > > > > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote: > > > > Wha

trailing comments prevent whitespace removal

I would expect make to remove trailing comments and then strip surrounding white space from variable definitions as usual but it seems that the comments prevent further stripping: $ cat Makefile # a classic var FOO = foo BAR = bar # and another but commented differently echo_some_vars:

Re: order-only prerequisites themselves get rebuilt when not needed

On Fri, Mar 7, 2025 at 4:59 AM Paul Smith wrote: > > On Thu, 2025-03-06 at 13:28 -0900, Britton Kerin wrote: > > In this example, I would not expect bar to be updated due to > > actual_source when foo is requested. The timestamp dependency chain > > should be broken betw

order-only prerequisites themselves get rebuilt when not needed

In this example, I would not expect bar to be updated due to actual_source when foo is requested. The timestamp dependency chain should be broken between foo and bar and Make should be able to figure that out when handling an explicit request for foo. Is this a bug? $ cat Makefile foo: | bar

line continuation causes make to report incorrect error locations

$ make --version GNU Make 4.3 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent per

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

On Thu, Dec 26, 2024 at 10:37 AM David A. Wheeler wrote: > > > On Dec 23, 2024, at 7:56 PM, Britton Leo Kerin > > wrote: > > > > Another crack at per-target .ONESHELL. > > > > The major problem with v3 was that the shared struct commands for > > implicit rules, .DEFAULT rules suffix rules etc. c

is it worth supporting implicit rule target patterns as .ONESHELL dependencies?

In writing docs I noticed that some directive targets support implicit rules patterns as dependencies (e.g. .NOTINTERMEDIATE) while others don't (e.g. .NOTPARALLEL). Would it be considered mandatory for e.g. .ONESHELL: %.o to be supported? Personally I never use implicit rules because static patt

how hard would it be to implement per-target .ONESHELL?

Thinking about it again this would be the single biggest upgrade I can think of for Make for me. I have so much code strung together with && \ but it's all in fairly large complex makefiles and there's no way I'm going to risk global .ONESHELL effects on targets I'm not actively reviewing. I'd lik

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

On Thu, Oct 31, 2024 at 9:19 AM David A. Wheeler wrote: > > GNU Make supports a number of special built-in target names > . > > I think it'd be helpful if some special target names could be listed as > *prerequisites* (foo: .PHONY

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Tue, Oct 8, 2024 at 7:16 PM Dan Jacobson wrote: > > Manual says: > >You can list the target pattern of an implicit rule (such as '%.o') >as a prerequisite of the special target '.PRECIOUS' to preserve >intermediate files made by implicit rules whose target patterns match >that f

Re: Making makefiles with primarily phony targets more friendly

On Wed, Aug 10, 2022 at 12:33 PM Jean-Baptiste Poittevin wrote: > > By using a lot of PHONY targets, I think you're closing a door to one make > greatest feature : not redoing those things that are already up to date. > > If you consider that every rule can generate a useful file (file containing

Fwd: Making makefiles with primarily phony targets more friendly

-- Forwarded message - From: Britton Kerin Date: Wed, Aug 10, 2022, 11:58 AM Subject: Re: Making makefiles with primarily phony targets more friendly To: Katherine Pata On Wed, Aug 10, 2022, 11:44 AM Katherine Pata wrote: > I often find myself using makefiles to han

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

On Sat, Jun 25, 2022, 1:48 PM Paul Smith wrote: > I'm trying to decide what the future is for GNU make's "build.sh" > bootstrapping script. As you may recall, this script is provided to > allow GNU make to build on systems which don't already have an instance > of make installed. Its goal is to b

Re: Bug in $(shell ...) I can't understand

On Sun, Feb 6, 2022 at 8:19 AM Dmitry V. Levin wrote: > > On Sun, Feb 06, 2022 at 11:23:03AM -0500, Paul Smith wrote: > > OK, someone posted a question to SO and that led me to an hour or more > > of banging my head against a wall trying to understand what's > > happening... and I can't. > > > > T

Re: .SILENT: clobbered by .SILENT: with_target

On Wed, Jan 12, 2022 at 6:17 AM Dmitry Goncharov wrote: > > On Tue, Jan 11, 2022 at 3:50 PM Britton Kerin wrote: > > It looks like the .SILENT: with a recipe clobbers the .SILENT: > > without > > Consider the following > > hello.tsk: > hello.tsk: hello

.ONESHELL causes quoting in .SHELLFLAGS to not work as expected

$ cat Makefile .ONESHELL: SHELL = /usr/bin/perl .SHELLFLAGS = -w -E 'use warnings FATAL => "all";' -E all: print 'it works' $ make all print 'it works' Can't find string terminator "'" anywhere before EOF at -e line 1. make: *** [Makefile:5: all] Error 255 $ Without .ONESHELL: the above wo

.SILENT: clobbered by .SILENT: with_target

.SILENT: (without prerequisites) doesn't work as expected when .SILENT: some_target (with prerequisites) is present: $ cat Makefile .SILENT: .SILENT: target_a target_a: echo target_a_recipe target_b: echo target_b_recipe $ make target_b

Re: [bug #61226] A regression prevents generation of missing included dependency files.

On Sun, Oct 17, 2021 at 4:44 PM Dmitry Goncharov wrote: > > On Sun, Oct 17, 2021 at 3:05 PM Britton Kerin wrote: > > > If I understand right that the idea is a special case for .d files > > The question being discussed is what to do when make cannot include a > make

Re: [bug #61226] A regression prevents generation of missing included dependency files.

On Sun, Oct 17, 2021 at 8:33 AM Dmitry Goncharov wrote: > > Follow-up Comment #8, bug #61226 (project make): > > > > Switching to -include robs the user of a useful message, should there be a > real issue. > > > I'm not sure what this means: in what situation do we lose a useful > message? > > -in

[bug #60297] optimize autodeps

Follow-up Comment #18, bug #60297 (project make): I strongly second Dmitry's proposal that something like .NOTINTERMEDIATE: (preferably with a no-dependencies-means-all interpretation) should be added. The IMO weird behavior of .SECONDARY where it effectively creates strange weak dependencies jus

.SECONDARY: unwanted effect of not causing rebuilds when intermediate files missing

I don't like how .SECONDARY: (without prereqs) causes make to not rebuild things wen intermediate files are missing, e.g. uncommenting .SECONDARY in this make file causes make to not rebuild even when foo.c.validation_stamp is removed: OBJS = foo.o #.SECONDARY: OBJS = foo.o bar.o

error checking version of $(shell)

On Mon, May 18, 2020 at 11:24 AM Pete Dietl wrote: > > Speaking of > > > return value of a call to $(shell) is available in $(.SHELLSTATUS). > > I think it would be a nice addition to have some global setting where > any failed $(shell ) > command automatically fails Make. Agreed. I have a coupl

Re: Idea: Add .COMMANDCHANGE and .CACHE

> I think .COMMANDCHANGE is not complex. > Since it caches the expanded command, at worst it will re-run a script > when before it would not have done so. > So it's relatively low risk; at worst, it'll run a command more often than > before. > It won't rerun if only an environment variable changes

Re: Idea: Add .COMMANDCHANGE and .CACHE

On Mon, Jun 10, 2019 at 5:14 PM David A. Wheeler wrote: > > On Mon, 10 Jun 2019 15:40:53 -0800, Britton Kerin > wrote: > > No, just the rules that :Makefile, which you can easily tune if it matters. > > Heck, you can include some_fragment.mk that has the recipes that

Re: Idea: Add .COMMANDCHANGE and .CACHE

On Mon, Jun 10, 2019 at 2:18 PM David A. Wheeler wrote: > > On Mon, 10 Jun 2019 12:10:26 -0800, Britton Kerin > wrote: > > The trickery required is not too fancy: > > > > foo.o: foo.c Makefile > > ... > > or >

Re: Idea: Add .COMMANDCHANGE and .CACHE

On Mon, Jun 10, 2019 at 9:20 AM David A. Wheeler wrote: > > Idea: Add .COMMANDCHANGE and .CACHE > > Problem: > > Paul Smith noted on Sun, 09 Jun 2019 22:11:32 -0400: > > Most of the requests I see these days that would require a "last state > > database" wouldn't be helped by md5 checks: mainly th

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. > > Problem: According to the docs .ONESHELL is global in effect, > so using it in an existing makefile requires a lot of rework. Strongly seconded, I would definitely use this. I've been

Re: Idea: Allow certain special targets as dependencies

On Sun, Jun 9, 2019 at 7:46 PM Masahiro Yamada wrote: > > On Mon, Jun 10, 2019 at 10:38 AM Paul Smith wrote: > > > > On Sun, 2019-06-09 at 18:46 -0400, David A. Wheeler wrote: > > > As syntactic sugar, > > > I'd like to see selected special targets allowed as dependencies. > > > When this happens

Re: Idea: Allow certain special targets as dependencies

On Sun, Jun 9, 2019 at 2:47 PM David A. Wheeler wrote: > > Idea: Allow certain special targets as dependencies > > Problem: > It's often the case that a target also needs to be a special target. E.g.: > .PHONY: all > all: do-this do-that > > Obviously this *works*, but it consumes many extra lines

Re: [bug #55137] $(file …) is executed too early when used in recipe

On Thu, May 16, 2019 at 7:37 AM Paul Smith wrote: > > I'm publishing this back to the list as I don't like to have private > conversations on these subjects; hopefully you don't mind. > > On Wed, 2019-05-15 at 11:19 -0800, Britton Kerin wrote: > > I agree that

thoughts and questions on order-independent Makefile method

Hi guys, I tried this on help-make but was didn't get any response, so I though I'd try again here. I'm interested in submitting patches to implement something like this, but I don't want to waste my time if it's a total non-starter. I'd like a --late-parse-rules (to parse all of rules after var

.SECONDARY should recognize pattern 'dependencies'

I want to be able to say something like this: .SECONDARY: %_openscad_poly %_openscad_poly: stl_outline_2_openscad_poly.perl %_profile.stl ./$+ >$@ so that make will always leave my generated intermediate file around. But this doesn't seem to work, so I have to either name

.SECONDARY documentation is slightly misleading

The documentation for the special .SECONDARY: target looks like this: .SECONDARY The targets which .SECONDARY depends on are treated as intermediate files, except that they are never automatically deleted. See Chains of Implicit Rules. .SECONDARY with no pre

wishlist item: namespaces for include

I would like to be able to tell make to automatically prefix all rules and variables that come from an include'ed makefile with a namespace prefix. So maybe this syntax: namespace foo_ include module_foo/Makefile The Makefile in foo might have targets build, test, and install, and a variable I

Re: wish: multiple target patterns in a static pattern rule

> bk> Implicit rules can handle multiple target patterns, is there any > bk> reason static pattern rules couldn't also? > > The reason is that static pattern rules are shorthand for writing > explicit rules, not longhand for writing implicit rules. > > That is, a static pattern rule is turne

wish: multiple target patterns in a static pattern rule

plit up the GOB_GENERATED_FILES variable into three and write three static pattern rules to get the effect I want, which is a bit clunky, especially since (with automatic dependency tracking) I don't have to care about header files much, and don't have any reason to put them in seperate vari