On Tue, Feb 17, 2026 at 5:16 PM Yair Lenga <[email protected]> wrote: > > Hi Britton, > > Thanks for taking the time to read my proposal. Good point about > documentation, should have included more use case. See below for some > additional example. If the proposal will be accepted - I look into creating a > documentation 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 limit > 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 > speeding 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 > download/process, and does not change frequently, Adding "valid-max" make it > possible to declare - It's OK with this target if it was created in the last > day - no need to reload. > > cache.json: private valid-max=1d > 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 commit. > when running heavy tests, it might not be practical to execute the full test > every time the remote artifact is recreated. Adding "valid-max=" on non-leaf > node, limit the execution of the tests to no more than once every 24 hours > (1d). > > tests.txt: private valid-for=1d > 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 > artifacts, and we wanted to force a policy that require the job to run (and > re-fetch) the remote artifacts, even if none of the local artifacts got > updated. 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=1d > 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 processes - > where the simple DAG rule may result in non-practical results. I'm sure that > there are other potential usages for building practical processes for > testing, deployment, database integration - and other systems that do not > provide exact modification timestamp, or when it's not practical to use > simple 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
