Rahul Butani rrbutani

nix-env -iA nixpkgs.netcat doesn't seem to install the nc output

netcat is just set to libressl.nc they are indeed the same derivation; these print out the same thing:

outputName is, however, different, as expected

the peculiar bit is that nix build (i.e. nix build '' -A netcat) will build and emit the nc output

	# The idea is to have `l2`, a toolchain, depend on something that
	# uses `l1` (a toolchain of the same type) to be built and to do so
	# without a transition but instead with `target_compatible_with`
	# constraints.
	#
	# We'll call this "something" the "compiler".
	#
	# So, we'll make the "compiler" require `:bootstrap_foo_toolchain`
	# and we'll create a platform that has this constraint and we'll
	# mark `l1` as also having this constraint.

	Probably not a good fit for `compdb` stuff (we'd need to aggregate the dumped args... which is actually literally what we already do.). Nevermind. This'd be perfect for compdb stuff.

	Regardless – this kind of thing is useful as a way to compare actions generated by (for example) `rules_cc` and a non-native implementation.


	nothing here is really of note if you've seen analysis tests using `skylib`; the only thing that might be interesting (or at least, was surprising to me) was that your rule doesn't need to be an `analysis_test` to poke at the actions generated for a target by another rule (even if that other rule isn't `_skylark_testable`)
	this is what the commented out bits are; the first thing is just a regular use of `skylib`'s `analysistest` but this doesn't let us actually poke at the `Args` used by actions (since Args are opaque at analysis time). `analysis_test`s cannot declare actions so we ditch the skylib `analysistest` glue and write our own aspect – and we can still access the actions generate

	run like:
	`bazel run //:test --foo=true --bar="20938r\"02\"3984" --baz=234`

	This isn't perfect; this requires you to include the generated header file to actually get those preprocessor symbols
	we can use defines in CompilationContext to not need that but I’d rather not do this since things added there propagate to all rdeps which
	kills the cache

	this also only works for skylib defined build settings (what they call flags); the accepted providers can be expanded if that’s an issue

	the flag aliases in `.bazelrc` aren't _required_; they're just nice

	a PoC for this question on the Bazel slack: https://bazelbuild.slack.com/archives/CA31HN1T3/p1637031391447100

	essentially, tries to have a transition on a rule use some attribute that was used to create a source of that rule using an aspect

	in making this I realized that we can actually achieve the exact same thing by just having the rule producing the _source_ also create a provider giving us the information we want (rather than having to extract it with an aspect)
	but that assumes we have control of that rule and can modify it and besides — this is a lot more fun anyways

	unfortunately none of this works; transition function aren't allowed to access providers on attrs
	this makes sense since transitions can _influence_ the providers exposed for a particular attribute

	(async () => {

	let getWindowSize = `
	tell application "System Events"
	set p1 to ((first process whose frontmost is true) of it)
	set w1 to p1's front window
	return {w1's position, w1's size}
	end tell
	`;

	An update to https://gist.github.com/rrbutani/f5d80af864e67d873ae4491111d9dcce.

	With the necessary `--incompatible` flags (see `.bazelrc`) this setup works all
	the way back until at least Bazel 3.7.

	This cquery command (pardon the `grep`s – they just strip out some noisy tool deps
	from the graph) should execute without any errors (no dependency cycles!) and yield
	a graph that shows `fake_compiler` being built twice: once by the host toolchain as
	needed by `stub_toolchain` and another time using `stub_toolchain`.