Carthage Build Error
jgainfort opened this issue · comments
Bug Template:
Expected Behavior
Carthage build / update works.
Observed Behavior
Carthage build fails
Observed on device(s):
- MacBook Pro 2018
Observed on OS Version(s):
- macOS 10.14
Open Questions
We've been seeing an intermittent issue with building the Mamba dependency through Carthage. The command that Carthage runs is:
/usr/bin/xcrun xcodebuild -workspace /PATH/TO/CARTFILE/DIRECTORY/Carthage/Checkouts/mamba/mamba.xcworkspace -scheme mamba -configuration Release -derivedDataPath ~/Library/Caches/org.carthage.CarthageKit/DerivedData/10.3_10G8/mamba/1.2.0 -sdk iphoneos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/qf/05lm714d1h9fz1r47bsw8xmc0000gp/T/mamba SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO
The error is that occasionally it can't find the <mamba/mamba-Swift.h> header in mambaSharedFramework/HLS\ Rapid\ Parser/RapidParserError.m.
The build failure appears to happen more consistently on the newer MacBook Pros (MacBook Pro (15-inch, 2018) 2.9 GHz Intel Core i9, for example). Personally I have not seen this occur on older models (MacBook Pro (15-inch, 2017) 2.8 GHz intel Core i7).
The suspicion is some sort of race condition combined with the new build system and its parallel builds that is exacerbated by the speed of the machine.
As an experiment, we have changed the build system to the legacy one (File > Workspace Settings... > Build System: from Xcode) within the Mamba workspace on, the newer machines, and run the command, and it passes successfully every time.
When changing back to the "New Build System (Default)" it fails consistently with the missing Swift header error.
- Has anyone experienced this before
- Could this have been solved in 1.3?
- What about 2.0? If so how difficult would it be to upgrade to the new API?
We've never seen this at comcast and several dozen people/CI machines are building mamba a lot. However, really new MacBooks are probably rare for the extended team, so...
I'm a little unclear, this is happening for the old 1.3 builds, 2.0? or both?
We will look at 1.3 and 2.0 and see what we find.
I spoke too soon. We can repeat this at Comcast.
I suspect that Xcode 10.3 introduced some additional build improvements that are causing this race condition, but I don't have the bandwidth currently to fully investigate and prove it.
I'm going to turn on legacy build for both 1.3.x (in 1.3.1) and 2.x (in 2.0.3).
@jgainfort if we fix in 1.3.1 is there any impediment for you to update to that version?
@dcoufal If its fixed in 1.3.1 we can move to that version immediately. Thank you! We also saw with 1.3 the deployment target was changed to 11 from 10. Was there a reason for this?
There was no reason intrinsic to the library. Comcast internally changed what versions of OS's we are supporting for our apps, and it looks like that change made it to this library as well (which it should not have, IMO).
Does this cause a problem for you?
We are targeting 10+. If thats still possible to maintain that would be very helpful. Are you in the video-dev slack by chance?
Yeah, that's fair. I'll put up another PR that reverts the deployment target changes for 1.x (we'll probably keep it for 2.0, at least for now).
Thank you.
Keeping it at 11 for 2.0 makes sense. Typically I see latest - 2 versions for apple support. So since 13 is coming out shortly that falls in line.
OK. I think we've fixed this for both branches (1.3.1 and 2.0.3).
If this happens again and you find this page, please open a new issue and reference this ticket by url https://github.com/Comcast/mamba/issues/66.