Britton, Thank you for you feedback - I agree 100% better to use existing syntax than to expand syntax.
I did some more experiments with the implementation I've submitted, and I found that there are valid use cases for using valid-max (and valid-for) in both situations (with and without private). As for error handing (on invalid values, e,g valid-max="last Monday", or other) - the implementation is aligned with current make behavior - errors and warnings are logged with the standard macros already available (DBS, DBF, ...) - with proper level (warning, info). This make the existing debugging, troubleshooting tools (-d, ...) works - no new options to learn. Yair. On Wed, Feb 18, 2026 at 10:38 PM Britton Kerin <[email protected]> wrote: > 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 >
