Description
In #1456, we discussed why source-build-reference-packages isn't part of the source-build repo, and what it should be called when it's put into a distro package as an output of a distro build. #1456 (comment):
I don't understand why it needs a separate package, vs getting consumed by source-build like other repos (coreclr, corefx, ...)?
we didn't want to increase build time.
I think it would make sense to:
- During a bootstrap build, always build source-build-reference-packages from source.
- This trades some build time against setting up a whole new distro package for this unique case (complexity for distro maintainer).
- We recently fixed some low-hanging fruit to dramatically improve the build performance [...]
- Set up generic build caches that can apply to any repo. (We need improvements in isolation, etc.)
- If a distro maintainer wishes, they can put caches from their source-build into distro packages so that if the commit doesn't change in the next release, they don't have to rebuild that specific repo.
- I believe we need something like this cache to reasonably put source-build CI in the repos, too.
- Take advantage of the generic build cache for source-build-reference-packages.
- This brings us back to where we are today, but more flexible and providing broader benefits (if a distro wants to use this infra).
The 5.0 source-build plan requires generic build caches ("intermediate nupkgs"), so it makes sense to adopt this for source-build-reference-packages. It might even be a good repo to experiment with the intermediate nupkg infra before we try to have other repos pick it up.
This also means source-build-reference-packages should use the Microsoft prebuilt ilasm/ildasm, rather than downloading a previously-source-built tarball (2GB) just for those tools. I think we can treat them like any other prebuilt tooling (SDK, Arcade).
We should probably create a release/3.1 branch in source-build-reference-packages. Normalizing the build scripts and inputs/outputs will likely break the way it's used in the existing release/3.1 N-1 and bootstrap flows.