Let’s compile the Mac OS X SecurityTool ourselves #4326
Conversation
Fuuzetsu
added
0.kind: enhancement
| configurePhase = "true"; | ||
|
|
||
| buildPhase = '' | ||
| python PrivateSDK.py -i ${osx_sdk}/Developer/SDKs/MacOSX${sdkVersion}.sdk -o PrivateMacOSX${sdkVersion}.sdk |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Maybe if I just mark it as unfree? I wanted to bundle the SDK up so we could construct it in other ways.
There was a problem hiding this comment.
That should be sufficient, I think.
copumpkin
force-pushed
the
mac-purity
branch
from
59d1829 to
d67c8c7
Compare
copumpkin
force-pushed
the
mac-purity
branch
from
d67c8c7 to
58ea86b
Compare
|
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. |
|
Now that I have a |
|
@shlevy your wish is my command |
| in stdenv.mkDerivation { | ||
| name = "MacOSX10.9.sdk"; | ||
|
|
||
| src = "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk"; |
There was a problem hiding this comment.
The environment variable SDKROOT already contains the path to the SDK, so no reason to hard-code it.
There was a problem hiding this comment.
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.
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:
xcodebuild.Adding this should make it possible for #3629 to work reasonably cleanly.