I have an XCode project (A
) referencing another project (B
). By default (as far as I understand it) XCode will implicitly build the configuration for the B
dependency that matches the configuration of the A
's target (e.g., "Debug"). But what if I want, say, A
to build as "Debug" and the B
to build as "Release"? How would I go about specifying that in XCode?
相关问题
- slurm: use a control node also for computing
- Xcode debugger displays incorrect values for varia
- Image loads in simulator but not device?
- importing files from other directories in xcode
- XCode Server: Opening import file for module '
相关文章
- Handling ffmpeg library interface change when upgr
- xcode 4 garbage collection removed?
- Xcode: Is there a way to change line spacing (UI L
- Unable to process app at this time due to a genera
- Popover segue to static cell UITableView causes co
- “Storyboard.storyboard” could not be opened
- didBeginContact:(SKPhysicsContact *)contact not in
- Build errors of missing packages in Visual Studio
Yes, this is not naturally supported by Xcode; when you build a target, it builds one configuration of itself and of all dependent targets.
The workaround, as Rob mentioned, is to have a dependent target that's an Aggregate Target type that comprises a single Run Script build phase, which simply invokes xcodebuild -configuration Release (or whatever).
This might help: if the configuration of the project
A
is not found, Xcode will buildRelease
config as a fallback (or maybe the first config of the list).Then you can "force" the link using this tip: Xcode custom build configuration causes "library/file not found" for static libraries
I don't know of any easy approach, but you can brute-force it by calling xcodebuild directly for the dependency with a "Run Script" build phase.
I know it was just an example, but if your real goal is that the sub-project be a Release (no symbols) build, then you may have a better experience by just building the sub-project into a library or framework and checking the resulting binary into your version control system. Whenever I have a piece of the system that seldom changes and that I don't want debug symbols for, I go ahead and build it as a static library and check it in. I often go ahead and move the code elsewhere as well (with a README file with the .a that says where the code is and how it was built). This saves time on both build and checkout and is invaluable for large projects in my experience.