search

mattgallagher / CwlSignal

A Swift framework for reactive programming.
ISC License
303 stars 33 forks source link

Command CodeSign failed with a nonzero exit code #16

Closed andreyz closed 7 years ago

andreyz commented 7 years ago

With Xcode 9 beta 2 with new build system enabled, I get

CodeSign /Users/xxx/Library/Developer/Xcode/DerivedData/xxx-gzzbuuauubqaczemizsmdnorzrub/Build/Products/Debug-iphonesimulator/CwlUtils.framework
    cd /Users/xxx/Projects/xxx/xxx-iOS/Vendor/CwlSignal
    export CODESIGN_ALLOCATE=/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    /usr/bin/codesign --force --sign - --timestamp=none /Users/xxx/Library/Developer/Xcode/DerivedData/xxx-gzzbuuauubqaczemizsmdnorzrub/Build/Products/Debug-iphonesimulator/CwlUtils.framework

/Users/xxx/Library/Developer/Xcode/DerivedData/xxx-gzzbuuauubqaczemizsmdnorzrub/Build/Products/Debug-iphonesimulator/CwlUtils.framework: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code

I include the framework manually, following all steps from the current README. Also with old build system enabled the project builds successfully.

mattgallagher commented 7 years ago

tl;dr The investigation was hard, the fix was not. Update your checkout to 7f39f259de684a331fe2cf6510d000842f9e87f5

The details...

CwlSignal uses a framework target named CwlUtils_iOS to build the CwlUtils dependency for iOS. In the new Xcode build system, this associates it with the package folder "CwlUtils.framework".

However, the CwlUtils_iOS target doesn't build the framework normally, it instead calls into xcodebuild to do this. The reason is that the underlying project is automatically downloaded as needed and if the target were configured normally, Xcode would complain that the project is missing before running the automatic download step remove it from the project.

We don't want to run this xcodebuild call every time (it takes a few seconds just to check dependencies) so we specify inputs and outputs to the build script and Xcode can avoid running the it if the download and the build product are in-sync.

All of this is a weird workaround for dynamically downloaded subprojects but none of it should be technically a problem.

The problem is that the build script specified its output as "CwlUtils.framework" – the same folder that the new Xcode build system already associates with the enclosing CwlUtils_iOS target. The new Xcode build system decided this was a circular dependency and was freaking out. I removed the problematic code signing and other problems cropped up. Eventually the build system stopped getting past the "Planning build" phase. Ergh.

Turns out that if I change the output from the xcodebuild script from "CwlUtils.framework" to "CwlUtils.framework/CwlUtils" (i.e. the executable inside the package) all the problems go away.

Fun times.