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.
This is a good way to test that plist works.
Sorry for the large diff. There are a bunch of cleanups in here that
needed to be done. Should make it possible to use in cross
compilation.
Without this xcbuild can detect an incorrect version for store paths
that have a sequence of digits in their hash.
ld: malformed 32-bit x.y.z version number: 85294
/nix/store/yz966rdvw1blblvzs15pxpcd85294isw-MacOSX.platform/Developer/SDKs/MacOSX.sdk
This includes adding a new xcbuild-based libutil build to test the waters a bit there.
We'll need to get xcbuild into the stdenv bootstrap before we can make the main build,
but it's nice to see that it can work.
Previously, this error was coming up in xcbuild:
ld: malformed 32-bit x.y.z version number: 1068638
It’s an interesting error because it only happens with certain hashes for the
nixpkgs sdk. For instance, on latest nixpkgs unstable channel, the hash for the
xcbuild sdk is:
/nix/store/w6mwbdaz9calyii0fyxspl51f1068638-nix.nixpkgs.sdk
that is an issue we pass -isysroot ${sdk} to clang where it will interpret that
hanging "1068638". It would probably go away as soon as the hash changes but
this hacky fix will solve the problem.
* Add setupHook for meson/ninja build
* libhttpseverywhere: Use meson/ninja setupHooks
* jamomacore: Remove superfluous ninja buildInput
* Remove obsolete ninja buildPhases
These are all handled by ninja's setup hook.
* lean2, xcbuild: fix build with ninja setup hook
Ninja is a runtime dependency here. However, cmake can generate Ninja
build files as well to satisfy the setup hook.
* qtwebengine: fix build with ninja setup hook
This is in preparation for the LLVM 4 upgrade (which gets more strict
about e.g., return false in xcbuild itself) and also for using xcbuild
more extensively in the Darwin stdenv bootstrap process, which is why I
killed the unnecessary gcc dependency in the toolchain. llvm-cov pretends
to be gcov anyway, so we're fine.
