Alternating between AppCode and xcodebuild causes full rebuild every time
The idea of sharing the DerivedData folder seems great except that it doesn't appear to be working as expected for me. I've been trying to switch back and forth between running tests with AppCode vs xcodebuild and it seems that every time I switch, I have to wait for a long rebuild. This is a pretty large swift project that is already slow to work with (3 minutes for a full build) and this is not making it any better.
I think I'm going to have to rollback to the previous EAP build until this gets resolved. Is anyone else seeing this?
Please sign in to leave a comment.
Hi Michael, Matt,
>I have to wait for a long rebuild.
Finally, we found the possible cause for it and will try to fix it in upcoming EAPs.
>Build in AppCode, then switch to Xcode, trigger a build and it fails with
Question - what is your use case, when you need to launch to build simultaneously in AppCode and Xcode? Just because it's not completely clear for us, which real-world use-case can lead to simultaneous building in both IDEs at the same time.
Yeah, I'm seeing the same. Build in AppCode, then switch to Xcode, trigger a build and it fails with:
error: remove /Users/doo/Library/Developer/Xcode/DerivedData/SimpleItems-evrelnzmjrjgwcfxrkvlzwhsctbg/Build/Products/Debug-iphonesimulator/XXX.bundle/en.lproj: Directory not empty
Trigger another build in Xcode and it rebuilds.
That's a good question. Normally I just do everything in AppCode, but I've been using Instruments a lot lately and using the Profile action from AppCode was flaky (ie. it would launch Instruments, but the app wouldn't always start correctly), so I need to launch the profiling session from Xcode. But in between those profiling sessions I sometimes need to do some debugging, which means I run it in AppCode again.
I can see this being a relatively rare use case, but from the description of the feature (sharing DerivedData), the whole point was to only have one copy of the build artifacts between Xcode and AppCode. If it's not going to work without requiring a rebuild when switching between the two, then maybe it's not worth supporting? Or put it behind a switch and let the user choose?
I think my case wasn't all that typical either. I was chasing down a problem where our TravisCI builds had async tests that were were having intermittent timeouts, but would always pass locally. I decided to use the xcodebuild command from our travis config to see if there was something special going on there. So I'd do a build with AppCode, no failures, then do a build with xcodebuild (would recompile) then had test failures. Every time I switched to the other tool I'd get a long rebuild.
To be clear, I never had simultaneous builds running as suggested by Stanislav. I would always wait for each build to finish before switching to the other tool.
I'm with Matt on this one. I can't imagine the point of sharing DerivedData if it doesn't speed up switching between AppCode and Xcode (and presumably xcodebuild). If there isn't a way of achieving that then I'll need a way to disable the feature, even if switching between the two isn't all that common. My current project is so slow to compile that even the threat of having to rebuild for any reason drives me nuts.
Ok, thanks everybody for sharing your use-cases and thoughts, it's really helpful in case of such changes. Finally, the initial change and it's idea was affected by this issue that did not appear during our internal testing. After fixing it should work as expected and as described in the blog post.
Sorry for the inconvenience, we are working on this issue right now and hopefully it will be resolved soon.
Wait, having Xcode and AppCode open at the same time is not the default?
I never thought about using just AppCode, always have the same project also open in Xcode. If you do Nib/Storyboard stuff you have no other chance anyways... Project Settings is another thing I do exclusively in Xcode.
IMHO most people will use both at the same time, as Xcode does not consume much RAM (probably the only good thing about Xcode).
I should clarify my situation in case I gave you the wrong impression: