New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let’s compile the Mac OS X SecurityTool ourselves #4326

Merged
merged 1 commit into from Oct 1, 2014

Conversation

Projects
None yet
5 participants
@copumpkin
Member

copumpkin commented Sep 30, 2014

This allows us to compile SecurityTool ourselves. There are several more Apple opensource projects that can be compiled this way that I'll slowly add.

Remaining sources of impurity:

  • Reference to absolute path to Xcode. This should be integrated with the xcode derivation (and the iOS wrapper chain that exists under mobile development) but it's not obvious how to do that yet.
  • Absolute reference to xcodebuild.

Adding this should make it possible for #3629 to work reasonably cleanly.

configurePhase = "true";
buildPhase = ''
python PrivateSDK.py -i ${osx_sdk}/Developer/SDKs/MacOSX${sdkVersion}.sdk -o PrivateMacOSX${sdkVersion}.sdk

This comment has been minimized.

@cstrahan

cstrahan Sep 30, 2014

Contributor

It's probably best to just use the absolute path to the sdk folder on the system; otherwise, anything depending on osx_sdk will try to pull down a substitute from Hydra, which is probably not good for legal and practical reasons.

This comment has been minimized.

@copumpkin

copumpkin Sep 30, 2014

Member

Maybe if I just mark it as unfree? I wanted to bundle the SDK up so we could construct it in other ways.

This comment has been minimized.

@cstrahan

cstrahan Sep 30, 2014

Contributor

That should be sufficient, I think.

@copumpkin copumpkin force-pushed the copumpkin:mac-purity branch from 59d1829 to d67c8c7 Sep 30, 2014

@copumpkin copumpkin force-pushed the copumpkin:mac-purity branch from d67c8c7 to 58ea86b Sep 30, 2014

@copumpkin

This comment has been minimized.

Member

copumpkin commented Sep 30, 2014

Pushed an amended commit with unfree licenses on the two SDKs (don't want hydra caching them, and I think that'll stop that). SecurityTool itself is under the APSL 2.0.

@copumpkin

This comment has been minimized.

Member

copumpkin commented Sep 30, 2014

Now that I have a fetchadc in #4327, we should be able to refer to the Mac OS SDK and xcodebuild in the store, but I don't have time tonight to set those up.

@copumpkin

This comment has been minimized.

Member

copumpkin commented Oct 1, 2014

@shlevy your wish is my command

@shlevy shlevy merged commit 58ea86b into NixOS:master Oct 1, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
in stdenv.mkDerivation {
name = "MacOSX10.9.sdk";
src = "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk";

This comment has been minimized.

@edolstra

edolstra Oct 1, 2014

Member

The environment variable SDKROOT already contains the path to the SDK, so no reason to hard-code it.

This comment has been minimized.

@copumpkin

copumpkin Oct 1, 2014

Member

Fair enough. I'm going to be changing this to (at least optionally) build on top of my fetchadc function soon, so I'll make sure this is sensible when I get back to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment