Re: new feature idea: ingesting processed rulesets

On Sun, 2023-06-11 at 12:29 +, Zoltán Turányi wrote: > My problem is that contrary to the make wisdom of writing a single > Makefile (to which I agree) most projects are still divided into > parts with separate build definitions. One can debate if this is good > or bad - for me it is a requirem

[bug #64339] $(filter) and $(filter-out) interpret "match" in surprising ways

URL: Summary: $(filter) and $(filter-out) interpret "match" in surprising ways Group: make Submitter: eliz Submitted: Thu 22 Jun 2023 10:07:13 PM IDT Severity: 3 - Normal

[bug #64339] $(filter) and $(filter-out) interpret "match" in surprising ways

Follow-up Comment #1, bug #64339 (project make): I believe that the use of PATTERN here is intended to make you understand that it's the same matching rules as with pattern rules or other uses of patterns, such as the patsubst function; patterns that don't contain a "%" always require the entire w

Re: new feature idea: ingesting processed rulesets

On Sun, 2023-06-11 at 12:29 +, Zoltán Turányi wrote: >> Couldn’t these be handled by creating a "namespace" concept for >> rules? One could merge 2 Makefiles by prefixing each target with the >> directory of the Makefile. This would make dir1/all different from >> dir2/all. Also in recipes vari

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 ha

Re: new feature idea: ingesting processed rulesets

> On Jun 22, 2023, at 5:39 PM, David Boyce wrote: > > > 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 worki