Rahul Butani rrbutani

see:

semantics of order-only deps:

when deciding whether to rebuild a target, the mtimes (or existence) of order-only deps are not considered
if the target is built (i.e. due to a normal prereq that was newer), it will wait on order-only deps
even if the target is not built (i.e. up to date), order-only deps will be scheduled for building (if out of date)

see comment in Makefile

what

tests the we can "project" particular files out of a TreeArtifact for consumption in downstream rules

the intent is that by doing this projection:

downstream rules that operate on files (not directories — i.e. not TreeArtifact aware) can consume our artifact
sensitivity in downstream targets is narrowed to only the files in the TreeArtifact that are projected out

We couldn’t find that file to show.

takeaways:

actions made by an aspect get to make files in the package of the target they are visiting
have "anonymous" action-like semantics, kind of
- will not get built multiple times if the same aspect for the same target is requested by two different consuming rules

bazel build //:yo @foo//:all

Background

See this gist about post-hoc action input pruning and the limitations w.r.t to caching.

buck2 has starlark APIs for (limited) dynamic deps (i.e. dynamic action creation albeit only with input subsetting): https://buck2.build/docs/rule_authors/dynamic_dependencies/

Bazel's internal dependency engine (skyframe) is capable of representing such dependencies and internal rulesets make use of this functionality (i.e. ThinLTO and C++20 module support in rules_cc) however — starlark rules have no way to express such graphs.

This PoC

buck2 is very explicit re: the interactions dep files have w/caching:

dep files can (after execution) narrow the set of inputs for an action
the input set of the action as known to your buck2 daemon will have this narrowed set but...
- the actual action cache key (as is given to disk/remote caches, etc.) will still have the full set of inputs
ultimately this means that as far as remote caching for cold builds is concerned, the action at hand is still keyed on all of its inputs — including the ones that are pruned
- this means that — for cold builds — if there have been any changes to any of the "pruned out" files since the last run of the action (+ cache population), the action will not hit in the cache
additionally, in the event that there are analysis-level changes that result in the starlark action being reconstructed (i.e. BUILD file is edited), we also lose the narrowed set of inputs

for changes that materially affect t

	0: [.] succ(a, ): add `1` to `a`
	1: [+] add(a, b): ret = a; ret = succ(ret) `b` times
	2: [*] mul(a, b): ret = 0; ret = add(ret, a) `b` times
	3: [^] exp(a, b): ret = 1; ret = mul(ret, a) `b` times
	4: [!] tetration(a, b): ret = a; ret = exp(ret, a) `b - 1` times (special case b = 0 -> 1)
	5: [@] pentation(a, b): ret = a; ret = tetration(ret, a) `b - 1` times (special case b = 0 -> 1)
	6: [#] hexation(a, b): ret = a; ret = pentation(ret, a) `b - 1` times (special case b = 0 -> 1)

	3 . -> 4
	3 + 4 -> 7 { ((((3 . ) . ) . ) . ) }

	use std::{
	cell::UnsafeCell,
	marker::PhantomData,
	sync::{
	OnceLock,
	mpsc::{Receiver, Sender, channel},
	},
	};

	// initialized from thread that can call ui stuff

	use clap::Parser;

	// NOTE: we want to model reporting args as an enum (of which we have multiple
	// copies) instead of a struct of vecs (one per option) because we wish to
	// preserve the order of these args.
	//
	// The clap cookbook entry for `find` provides a reference for how to model
	// these kinds of "order matters" flags:
	// https://docs.rs/clap/4.5.16/clap/_derive/_cookbook/find/index.html
	//