I'm trying to automatically exclude a library from my release build, but have it present in my adhoc build.
I've found the file build file under ~/Library/Developer/Xcode/DerivedData
I've deleted them, between builds, to make sure they were getting created as the modified date was the same. However, the build is the same size...
Remove from the libaray target.
Make AdHoc build configuration by copying the Release build configuration.
Add -lTestFlight in the other linker flags section of AdHoc build configuration.
Taken from http://d.hatena.ne.jp/basuke+en/20111122/1321924385
Any ideas ?
You can easily manage this by looking at your Build Target in XCode.
Select the one which you do not want to contain the library then click Build Phases and under the sections
Link Binary With Libraries
Copy Bundle Resources
You should be able to remove the unwanted library for that particular build.
Related
Our project uses CMake to configure our code. We use Ninja along with a distributed build system. A number of people on our team use Eclipse CDT. We run CMake with the "Eclipse CDT4 - Ninja" generator and the result is generally pretty good.
The issues is that any time a CMake file is changed and you ask Eclipse to build the code it regenerate the eclipse project file overwriting any manual changes you've made to the project.
For example the default build command that it provides the eclipse project is /usr/bin/ninja when in fact I want to take advantage of our distributed build system and set the build command to /usr/bin/ninja -j16. It would be nice if I could have the project file that CMake generates automatically include this setting change.
The other setting I am most interested in preserving is the C/C++ Project Paths->Source. As a general rule we place our CMake build directory as a sibling to the main project directory i.e. ./project ./build. We want to include some files in the build directory in the Eclipse index to make code completion and other tools work better. The default project doesn't include the build directory in source path and thus it does not get indexed.
Is there some way to remedy these issues?
I found a solution to build command issue.
When you run cmake to generate the eclipse project include the additional argument:-DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100. I haven't confirmed but I believe a similar command is required for eclipse make projects -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j100.
Unfortunately this feature is poorly documented and I have not found a solution to my other issue.
My project contains two targets, the main application and a separate target for testing. The main target builds no problem but the test target fails with the following linker warning:
"ld: warning: ignoring file .../libj2objc_main.a, file was built for archive which is not the architecture being linked (i386)"
It seems like this is a common problem, and there are several posts that deal with solutions, from setting the "Build Active Architectures Only" flag to No (or is it Yes?) to using shell scripts to force Xcode to build a fat binary. (Using lipo I've confirmed that the compiled .a file only contains the x86_64 binary.) It's really bizarre that when I create a new test target and run the default XCTest suite everything builds fine, but if I attempt to add the Pods config file to the test target in Info -> Configurations and run the tests again everything blows up. This has never been a problem in other projects.
My question is why is this only failing for the test target? I'm using the same architecture in both the regular and test builds, so why is the .a only being a problem in the latter case?
So it turns out that the reason things weren't building was because (unbeknownst to me) my team was manually managing the header search paths. I'd encourage anyone working on a team to check the header search paths inside the primary target and see if they're all being added individually. If they are, you'll similarly need to add any test-specific headers manually in your test target.
I have a main project, which includes a nested library project which produces a libCore.a library.
Both of the projects have the two configurations debug and release. Now if I build the main project with a given configuration, how can I make sure that this is passed down to the library project as well?
Make your project directly dependent on the libCore project. Do achieve this, do the following:
Drag the libCore project file to your main project. It happens sometimes, that only the xcodeproj file is moved. If this happens to you, restart XCode (this happend to me with RestKit and the latest XCode).
After point 1 is done and you can browse the dependency project, go to your target build phases and add the libCore as the target dependencies.
Link against libCore.a by adding in the Link Binary with Libraries phase.
These are 3 basic steps, I don't know what the libCore is, if it needs to be linked with any other libraries then you will also have to link your target against those libraries.
I am trying to add a dependent project in XCode 4. The link to the project is this: https://github.com/jverkoey/ObjQREncoder
The author described a way to add this but it's for XCode 3. I am trying to add it to XCode 4.
I dragged the project inmy frameworks, then went to Targets and QREncoder in Target Dependencies. Then I added libQREncoder.a in "Link Binary with Libraries". Then I added this for header search path "src/Classes".
When I include "QREncoder/QREncoder.h", it gives me this error: file://somePath/FINALQRAppDelegate.m: error: Lexical or Preprocessor Issue: 'QREncoder/QREncoder.h' file not found
This is how my project is set up:
FINALQR is my project to which I am trying to add the dependency and the dependency project is in src.
Thanks.
The problem is it doesn't recognize the QREncoder class.
Only Xcode 4 workspaces benefit from shared build folders across multiple projects. From the main menu, select File > New > New Workspace... Save the workspace, then drag your subprojects into its Project navigator panel.
Be careful where you place them (make sure you're not making one project a subproject of another within the workspace) so that they're all top-level projects within your workspace. This will cause them to share the build folder and automatic dependency detection should work.
Unless, of course, you have custom search paths set in your targets' build settings. :-)
I think your problem is you need to set the following as your search path:
"$(SRCROOT)/src/Classes"
not
"src/Classes"
If you already have an Xcode4 project, you should be able to drag QREncoder into it as a subproject, as I think you have already done, and then add the .a file, also as you've done.
I've created a custom control and a framework/IB plugin for it using the IB3 plugin template.
According to the docs the plugin should be built right into the resources directory of the framework. When I build my project the plugin is in the configuration folder (Debug) along with the framework instead.
This is the same behavior right out of the box when I create a new template. I tried changing the CONFIGURATION_BUILD_DIR to be $(BUILD_DIR)/$(CONFIGURATION)/FrameworkName.framework/Resources/ but got no change.
For grins I also tried messing with the install path, but also got nowhere. I've checked out a couple other open source projects to check their build settings, but they're identical to my own and yet their plugin is built and put into the resources directory as expected.
Don't mess with build settings. Instead, add a "Copy Files" build phase to the framework target. In the inspector for the copy files build phase, set the directory to "Resources". Add the plugin to this build phase by dragging the plugin product from the "Products" group in the "Groups & Files" tree in Xcode.
To get the built product of one Xcode target to be included in the resources directory of another Xcode target's product, you should find the product in the groups and files tree and drag the product into the copy "bundle resources phase" of the other target. You should also add a target dependency between the two targets with the get info panel for the target.
If you're seeing the built plug-in in the build products directory that does not mean that it wasn't also copied into the framework's resources directory. Xcode builds all targets into the build directory, and then copies (not moves) them into their final destination - which in this case is the framework's resources directory. One reason for this is that a product can have multiple final destinations.
Thanks, Barry. When I tried using a copy files build phase, IB wasn't able to resolve the connection between the framework and the plugin. It couldn't find the associated plugin for some reason.
However, after endless fiddling, I found that I was closer than I thought. Changing the CONFIGURATION_BUILD_DIR to:
$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/FrameworkName.framework/Resources/
and updating the framework search paths solved the problem for me. This isn't the behavior of the plugin template (at least on my machine) out of the box, so hopefully this will help someone else.