iOS Link Binary with library for debug only - iphone

I have a bit of a problem with setting different configuration for my project. I have two versions of the same static library. One has logging enabled, the other doesn't.
I am using two different xcconfig files for Debug vs. Release. In these files I specify the library and header search paths for the two variants of the static lib. So far so good.
However, in my build settings I can't see a way to conditionally link the actual library. I.e use the debug variant for Debug and the release for Release.
Any ideas?

You need to link the library using the "Other Linker Flags" build setting, rather than the standard "Link Binary With Libraries" UI. The build setting can be changed depending on the configuration:
Click the triangle and you can give different values for Debug/Release. You will need to use the -l flag. For example, for a filename of libMyLib.a use the flag -lMyLib. You may need to edit the "Library Search Paths" to search the appropriate location.
If the filenames for the debug and release version are the same and you don't want to change them, put them into their own lib/Debug and lib/Release directories respectively. Then edit the "Library Search Paths" build setting adding either "$SRCROOT/lib/Debug" or "$SRCROOT/lib/Release" for the appropriate configuration.

Related

Remove static library based on certain preprocessor macro

I have one functionality and it is depending on one static library. Actually, Apple is not allowing this static library because of few reasons. So, for now we have decided to add one Preprocessor macro and based on that functionality should be switch on/off.
I have switched my code to behave based on that Preprocessor macro. But I didn't find any to link or unlink the library based on preprocessor macro. I can not allow to link the library all times, as I have already told apple is not allowing it.
One solution that I already know : I can create the multiple target. But problem is that my app has already lots of targets. So, again to manage this I have to create one more target for each target those are already created.
Any help will be appreciated.
Edit:
I have created configuration like Francesco suggested. But One quick question I have let's say If I will remove the path of library from "Library Search Path" then that library will not be linked to app? Because that library is still in target of App.
Instead of targets you can create multiple configurations. And you can change the linker flags there.
I did this think for Sparkle framework (which is not allowed on App Store)
EDIT:
To create/manage the configurations click on the project in the sidebar. Then in the main window select again the project, not the targets, and select the "Info" tab.
Together with Deployment Target selection and Languages you will find a Configuration section.
You can add or remove configurations from there.
Then to launch it you have to go to Product -> Scheme -> Edit Scheme -> Build Configurations.
You can duplicate an existing scheme and choose the correct configuration from there.
You can remove the static library from the list of linked items by setting a (somewhat undocumented) Xcode build setting:
EXCLUDED_SOURCE_FILE_NAMES = libUnwanted.a
You can do this in an .xcconfig file or in the normal target build settings UI (by adding a custom build setting). If you for example set this in the "Release" configuration Xcode will include the library in the "Debug" build but omit if for the release build.
EXCLUDED_SOURCE_FILE_NAMES works with all kinds of files that can be added to a target: source files, resources, libraries, ...
Here's how to do this step by step:
Open the target build settings by clicking on the blue project icon in the Project Navigator and select the Build Settings tab.
Click the plus icon to add a "User-Defined Setting"
Name the setting "EXCLUDED_SOURCE_FILE_NAMES"
Expand the Configurations for the setting and set the "Release" value to the name of your unwanted library.
Credit of this answer goes to Nikolai Ruhe & Francesco
I have combined the answer of both and I got the solution.
Here are the steps that I followed.
Created new configuration. ( To know how to create configuration see
the answer of Francesco)
Added flag EXCLUDED_SOURCE_FILE_NAMES in user-defined setting of Build settings. (For steps see the answer of Nikolai Ruhe). And in this flag I have added the name of my static library under the my custom configuration.
Here is a good tutorial that will definitely help you : Remove tesflight from Distriubtion

Including QuickDialog into Xcode 4.2 Project

I try to include QuickDialog into one of my projects and just can't get it to work.
I did the following:
downloaded it from github
copied it into my project directory
drag and droped the QuickDialog.xcodeproj file downloaded from github
previously from Finder to my project
in the Build Phases, Added QuickDialog (the lib, not the example app)
as a Target Dependency
in the Link Binary With Libraries section, added the libQuickDialog.a
library (this turns red actually don't know why)
In my Prefix.pch file, add: #import <QuickDialog/QuickDialog.h>
cause this didn't work I also tried the following:
added -Objc and -all_load to my "Other Linker Flags"
added $(SOURCE_ROOT)/escoz-QuickDialog-b5f67f1 to "User Header
Search Path"
this also didn´t work I always get the error QuickDialog/QuickDialog.h file not found at the line #import <QuickDialog/QuickDialog.h>
What do I do wrong?
Did you not do exactly these steps too, from the documentation:
Locate the “User Header Search Paths” setting, and set the Release value to “${PROJECT_DIR}/QuickDialog” (including quotes!) and check the “Recursive” check box.
The Debug value should already be set, but if it’s not, change that as well.
Also locate the “Always Search User Paths” value and set it to YES.
Finally, find the “Other Linker Flags” option, and add the value “-ObjC” (no quotes).
These instructions do work.
So the solution to this problems are, as posted in the comments, the quotes on “${PROJECT_DIR}/QuickDialog” as you can see there two different quotes.
The solution is to NOT copy it from the documentary, instead just type it yourself and your are fine.
It should look like this: "${PROJECT_DIR}/QuickDialog"
Thats the trick.

Eclipse/CDT editor not picking up project-defined symbols in coloring ifdef'ed out sections

The problem I'm seeing is that under preferences, C/C++ Defined symbols for different Configurations/targets aren't showing up in the code coloring.
When I change the active build configuration in the project menu, I would expect the editor & code coloring to pick up the symbols from the project settings, but it only seems to be picking up the symbols for one of the targets.
Is there any way to have the code coloring for ifdef'ed code follow the active build configuration?
I solved this problem on my system by setting 'Window->Preferences->C/C++->Indexer->Use active build configuration'
In response to phord's comment. After changing the indexer setting to "Use Active Configuration" you need to change the active conf of the project to something else and then back. Then it picks up the changes.
just a small addition to the symbols option:
give it value 1
what worked for me is this:
copy the define name to clipboard(lets say we have: #ifdef DBG_TYP_1)
select the project in project explorer
go to - Project->Properties->C/C++ General->Path and Symbols
in the "# Symbols" tab
add symbol DBG_TYP_1 with value 1
thanks for the tips !
Try playing around with your project's Discovery Options. (Right-click on the project, choose Properties, go under C/C++ Build, and choose Discovery Options.)
You may need to rebuild your project after changing its build configuration in order for Eclipse to rerun its discovery, or you may need to change the discovery options for each configuration to cause them to generate different results. (Sorry, this isn't an area of the CDT that I've played much with.)

Specific compiler flags for specific files in Xcode

I've been tasked to work on a project that has some confusing attributes.
The project is of the nature that it won't compile for the iPhone Simulator And the iPhone Device with the same compile settings. I think it has to do with needing to be specifically compiled for x86 or arm6/7 depending on the target platform.
So the project's build settings, when viewed in Xcode's Build Settings view doesn't enable me to set specific compiler flags per specific files. However, the previous developer that worked on this project has somehow declared the line:
CE7FEB5710F09234004DE356 /* MyFile.m in Sources */ = {isa = PBXBuildFile; fileRef = CE7FEB5510F09234004DE356 /* MyFile.m */; settings = {COMPILER_FLAGS = "-fasm-blocks -marm -mfpu=neon"; }; };
Is there any way to do this without editing the project file by hand? I know that editing the project file can result in breaking it completely, so I'd rather not do that, as I obviously don't know as much as the previous developer.
So to clarify, the question is:
The build fails when compiling for simulator unless I remove the -fasm-blocks flag. The build fails when compiling for device unless I add the -fasm-blocks flag. Is there a way to set this flag per file without editing the project file by hand?
This blog post by Joshua Nozzi explains how to do this in Xcode 4, where he says:
... select your project in the Project Navigator, select the relevant target (you may have only one), then select the Build Phases tab. Expand the Compile Sources phase and viola! A Compiler Flags column lets you set each file’s flags for that target.
You can define additional compiler flags for individual source files as follows:
first select the target you are going to build
right click on the source file
select "Get Info"
click on the "Build" tab
define your additional compiler flags
However it sounds like a better solution in your case is just to duplicate the target and have two targets - one for an actual device and one for the simulator. Inherit common build settings from the project level and just tweak the per-target build settings as necessary.
Call GetInfo for the specific file, you can set the Build settings there for this file. See also the XCode Project Management Guide about this.

xcode build configurations search paths

my iphone app builds fine in debug configuration, but when i change it to release, i get hundreds of errors, starting with "CoreServices/CoreServices.h: No such file or directory" in AudioFileComponent.h - part of the AudioToolbox framework.
i can't find where in the project/build settings is responsible for this.. thanks for any help.
I would recommend the following:
Open up your debug target's build settings by right-clicking on the target, hitting "Get Info", and selecting the Build tab.
Select All (Command-A) so the entire contents of the Build setting panel is selected, then copy it to the clipboard.
Paste the contents of the clipboard to an empty text document
Repeat steps 1-3 for the release target of the same project
From there you can use a diff utility or some other method to compare the contents of the two files, which will show you the settings that differ between the two configurations. Some of them will make sense (e.g., optimization settings) whereas others will not. Most likely there is a setting that differs between the two that will resolve your problem.
Another thing you can do is build one of your source files in debug mode, and in the Build Results window copy the contents of the command line to a text editor. Repeat for release mode. Then, replace each space in the command line with a newline (\r). From there you should be able to do a rough side-by-side evaluation of the differences between the two compile instructions, and may be able to figure out what's missing from that.
In general this helps you get a better feel for exactly what XCode is doing under the hood to build your project, which is a good strategy to practice no matter what tool you are using for development.
i think the problem was because i had the audiotoolbox package in the wrong place, it wasnt in system/library/frameworks like it should have been. (this doesnt explain why it built ok in debug though)