Without the change build fais on `master as
https://hydra.nixos.org/build/249027078:
/build/source/Libraries/libutil/Headers/libutil/Permissions.h:23:18: error: 'uint8_t' does not name a type
23 | using Base = uint8_t;
| ^~~~~~~
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Sometimes, builds only call xcrun for very basic detection. This exposes
a `xcbuild.xcrun` that has a significantly simpler closure. (It's just
some files and shell scripts.)
"Real" xcodebuild allows using `xcodebuild -version -sdk` without
an sdk version argument, which will dump sdk info for all the
installed sdks.
Bazel"s "xcode cc toolchain setup on mac" process uses this
to determine which SDK version is actually installed. This
change allows using a nix-supplied pinned compiler and build
system under bazel.
Bumping the MacOS target version to 10.12 signalled xcbuild that
libcompression is available on Darwin, but libcompression is not
OSS (even though an LZFSE reference implementation is), and it is not
part of a framework for us to make impure, so this patch disables it.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
Lots of stuff has gotten moved around. Many security libraries have been merged
into the Security monorepo. I’ve cleared them out for now, we will
need to modify Security to build them!
This also moves some things around to more clearly separate
bootstrapping the stdenv from everything else. We want the “normal”
mode to be the non-bootstrapped version. When you ask for “Security”,
you want the actual built software, not a crippled one.
- Add TARGET_OS_OSX to darwin.libSystem. Looks like something
introduced in 10.12. TARGET_OS_MAC is only set when building for
desktop (iOS will have TARGET_OS_MAC set)
- Bump darwin.dtrace
- Bump darwin.libpthread
- Remove SmartCardServices, libsecurity*, etc.
- Install some more headers for darling.
sometimes we want the "SDK" version from xcbuild so we do something
like:
$ xcbuild -version -sdk MacOSX10.10
SDKSettings.plist - MacOSX10.10 (MacOSX10.10)
SDKVersion: 10.10
Path: /nix/store/6k7crm1n4drf09ga0dwvbmb59x4zl2i2-SDKs/MacOSX10.10.sdk
PlatformPath: /nix/store/vhfwb1znfy65s2xs27j8xribk6mp6lbw-Platforms/MacOSX.platform
ProductName: Mac OS X
ProductVersion: 10.10
This was previously overriden by the current xcode version so you
would get:
Xcode 9.4.1
Build version 17E189
This should fix the other usage of -version in nodejs 6.x.
Not every package that needs xcbuild will want to use its build phase.
I have moved the xcbuild setup hook to the new attribute xcbuildHook.
This means that dontUseXcbuild is no longer needed. If you just need
to call xcbuild on its own you can just refer to xcbuild.
This reworks some of xcbuild logic to make it more compatible with
Apple’s SDK.
- Add a fake version of xcrun & xcode-select
- Cleanup platform generation. Clang does not like having 20 char
hashes in sysroot so it is much easier to just build the parent
directory for each runCommand. This is a little awkward but I have
renamed everything with an added ‘s’ to make the distinction more clear.
- Cleaned up wrapper.nix in some different ways
- Reuse some versioning logic so that we don’t end up with two
different versions of Xcode or SDK reported.
A few from cctools were missing. Ideally they would not be needed but
xcode provides them & we pretty much need to as well for a lot of
xcode projects.
