Rahul Butani rrbutani

observations:

path mapping does not really[^1] "mask" out the repo name from non-main repo paths: source files OR generated artifacts
- this means that whether you build a particular target (or really produce a particular action for the target) when that target is in the main (root) repo vs. when its in an "external" repo effects the paths used in the action
- i.e. you will not get cache hits if you build //:your_target and then pull your repo into another bazel workspace as @foo and build @foo//:your_target
- TODO: would be nice to repo names as well...
path mapping silently falls back to using unmapped paths if the set of mapped paths has any conflicts (see :example_both)

note that ctx.actions.run(_shell)'s inputs does influence path mapping and does appear to factor into how conflicts are detected but... if you try to add a path to the command line (i.e. via arguments) that you haven't listed in inputs it isn't an error — some path mapping heuristi

Enforcement of allowed dep edges

the idea is to have testonly-esque checks

consider a project where we want to partition content (for an existing rule) into three categories:

"open-source"; a.k.a. oss
"proprietary"; a.k.a. prp
"development-only"; a.k.a. dev

see https://www.gnu.org/software/make/manual/html_node/General-Search.html

from the perspective of a recipe (i.e. automatic variables), prerequisites are "rewritten"; if they're resolved to a directory in VPATH, the prereq is prefixed with that directory

see here for .section directive flags and _type_s

also see the solaris ELF object file format docs

https://c.godbolt.org/z/T4j9GP91n https://assembly.godbolt.org/z/TGnGMWWWd

conflicting linker section flags?

i.e.:

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.

	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