Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
- Use the 11.0 SDK instead of the 10.12 one on x86_64-darwin;
- Use `NIX_CFLAGS_COMPILE` and `NIX_LDFLAGS` to pass flags to the
compiler instead of patching the Xcode project files; and
- Use xcbuild to build the project.
MATE currently uses a scope, but it doesn't actually expose that scope
to callers, which makes overriding packages in overlays quite difficult
as you have to figure out where each package is plumbed through in the
attrset. You end up with contrived expressions like:
mate = super.mate // {
# ...
extraPackages =
(self.lib.remove super.mate.whatever super.mate.extraPackages)
++ [ self.mate.whatever ];
};
This change exposes the scope so that we can use overrideScope' in
overlays instead.
manifest-versions never seems to contain the release build any more,
so we can't use it to find the version of crosvm being served to CrOS
devices.
Instead, I've changed the update script to take the latest version of
the appropriate crosvm Chrome OS release branch. This is the branch
that gets served. Every release, it is branched off from the
"chromeos" branch (which is the one that passes Chrome OS QA), and
then collects any critical fixes over the lifetime of the release.
With this change, I've introduced a new, simplified versioning
scheme, e.g. 100.0. The tip build is always 1:1 with the Chrome
version, so having both of those is redundant. The other number is
the number of commits that have been added to the release branch after
branching from the chromeos branch, so that the number will go up if
we update to include a new commit from the same release.
The old dashboard no longer exists. Currently, the platform version
being served doesn't exist in manifest versions, but that was also a
problem we had before sometimes.
Otherwise, we might only match a prefix of the version. (Although
it's not likely to be a problem in practice — I doubt we'll end up in
a situation where there's a buildspec number 10x the one we're looking
for.)
