Re: [PATCH] make: add valid-for and valid-max target TTL support

On Tue, Feb 17, 2026 at 5:16=E2=80=AFPM Yair Lenga <[email protected]> w=
rote:
>
> Hi Britton,
>
> Thanks for taking the time to read my proposal. Good point about document=
ation, should have included more use case. See below for some additional ex=
ample. If the proposal will be accepted - I look into creating a documentat=
ion pages for "info make" for various use cases:
>
> Is it usable only for leaves ?
> - Short answer: It can be used also on non-leaves to limit rebuild, or li=
mit reuse of targets. In it's simplest form - it can be used on leaves that=
 (including leaf that depend on "PHONY" targets).
>
> Below are the main use cases where new features will help, all involve sp=
eeding up process when there is "expensive" operation, which can be skipped=
 MOST of the time, and it's OK to be slightly behind. I'm implementing all =
of those cases with combination of macros/shell commands.
>
> 1. Cache (original example):
> Assuming the build need a remote resource that take lot of time to downlo=
ad/process, and does not change frequently, Adding "valid-max" make it poss=
ible to declare - It's OK with this target if it was created in the last da=
y - no need to reload.
>
> cache.json: private valid-max=3D1d
> cache.json:
>           curl -o $@ https://example/api
>
> 2. Reduce excessive updates.
> In some cases, the build process depend on files can be updated multiple =
time. This could be a CI process that produces new artifacts on every commi=
t. when running heavy tests, it might not be practical to execute the full =
test every time the remote artifact is recreated. Adding "valid-max=3D" on =
non-leaf node, limit the execution of the tests to no more than once every =
24 hours (1d).
>
> tests.txt: private valid-for=3D1d
> tests.txt: /path/to/remote/artifact.tar
>           tar xvf $<
>           run_tests
>           touch $@
>
> 3. Expiration of targets, when dependencies are incomplete.
> In some cases, it's not possible to describe the full set of dependencies=
 (e.g., when it's dynamic), or when dependencies are "noisy". For example -=
 I had a case where a job had a dependency on remote artifacts and local ar=
tifacts, and we wanted to force a policy that require the job to run (and r=
e-fetch) the remote artifacts, even if none of the local artifacts got upda=
ted. Adding valid-max indicate that the job should be re-make if it's older=
 than 1 day, even of leave dependency was updated.
>
> job.txt: private valid-max=3D1d
> job.txt: /path/to/other/artifact.tgz
>       tar xvf $<
>       curl .... | tar xvf -
>       run_job.sh
>       touch job.txt
>
> I hope that those examples show how the new functionality make it easier =
to address common use cases when using make for CI/data integration process=
es - where the simple DAG rule may result in non-practical results. I'm sur=
e that there are other potential usages for building practical processes fo=
r testing, deployment, database integration - and other systems that do not=
 provide exact modification timestamp, or when it's not practical to use si=
mple DAG rules.

Ok.  I don't know much about CI or the cases you describe so my
comment is limited to the use of the variable syntax to add some new
functionality to make.  I think it's an appropriate strategy for Make
(instead of expanding the syntax) but care is needed to make sure it's
completely clear what's going on, and that wrong uses give clear
errors.  So I wonder what happens if the private modifier is omitted?
I tend to think both of these should be errors.  (Maybe they already
are I haven't looked at the patch itself).

Britton