[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hot to write pattern rules for suffix deletion
From: |
Philip Guenther |
Subject: |
Re: Hot to write pattern rules for suffix deletion |
Date: |
Thu, 4 Jan 2024 23:50:44 -0800 |
On Thu, Jan 4, 2024 at 8:51 PM Stephen Touset <stephen@touset.org> wrote:
> I have a set of files in a project that need to be preprocessed through
> `envsubst` to render their output. The targets of these templated files
> are a mix of different file types, so they aren't rendered to files with
> a consistent extension. Further, not all files with those target
> extensions need to be rendered from templates. For example:
>
> a.yaml.envsubst // a.yaml should be rendered from this
> b.json.envsubst // b.json should be rendered from this
> c.json // should not pass through a rendering step
>
> I would like to express this in a make rule. Instinctually, I want to
> reach for something like
>
> %: %.envsubst
> envsubst < $< > $@
>
> Obviously this rule isn't correct.
Can you explain why you don't believe that to be correct? Given that a
pattern rule only applies when the prerequisites either exist or make knows
how to create them, why wouldn't that work?
> But I'm a bit at a loss for how to
> express what I want through make rules. One approach that I considered
> was using `$(shell find ...)` to get a list of these templates and
> generate rules for each one. Unfortunately in my case, that would be
> quite difficult because one file might go through *multiple*
> preprocessing steps:
>
> d.json.envsubst.gz // d.json should be decompressed then rendered
>
That could be handled in either of two ways. If .gz only needs to be
handled in the exact .envsubst.gz combo, then simply having a second
pattern for those that does the right thing would work:
%: %.envsubst.gz
gzcat $< | envsubst > $@
Alternatively, if you use .gz in combo with all sorts of suffixes AND
decompressing to a file and then operating on the file isn't unreasonable
or a pessimization that you want to avoid, then you can just have a general
rule for .gz files that make can figure out how to chain with the first
above:
%: %.envsubst
envsubst < $< > $@
%: %.gz
gzcat < $< > $@
So now I'd need to have some overcomplicated logic to write out the
> resulting rules:
>
> d.json: d.json.envsubst
> ...
>
> d.json.envsubst: d.json.envsubst.gz
> ...
>
Why? I don't see why you would need to do that.
Philip Guenther