I want to replace some placeholders in my .pbxproj file with real data before the compilation occurs. In a plain text of .pbxproj I have entries like REPLACE_ME_BUNDLE_ID or REPLACE_ME_TEAM_ID in place of app's bundle identifier and Development team respectively.
May I use a Run-script phase for that?
Or is Xcode known for saving the .pbxproj in some safe place before the build and use it from there?
UPD: I do not use any xcconfig files, nor these placeholder values are declared anywhere. The question specifically is whether Xcode copies and hides the .pbxproj before the build starts and uses that copy, or am I allowed to modify the .pbxproj during the build?
These values will be replaced by the actual values before compilation.
Compilation will not succeed if these values are used as-is.
The values will be picked up based on the project 'Configuration' currently set as-per the build scheme (or as-specified in the build command if that is how the build has been initiated). You may locate actual values of these placeholders under build settings of your xcode target, and in-some cases they might come from the environment.
If this helps, kindly consider marking this as the answer, or else please comment and let me know further detail about what you're trying to do, so that I may give it more thought and try to to help you.
Related
I am currently working on an iOS project in XCode that uses configurations to specify the different API environments my app can connect to. Additionally, I use targets to override one of my project configuration's user-defined values to specify a particular configuration file to use in the app. However, this is the only value that changes in the target. I work with multiple different configuration files (maybe 10 to 20 at a time) and creating a new target for each file to update one value seems clunky.
My question: Is there a way to pass this one value in from the scheme instead of setting it in the target?
I have seen that there is a pre-build script that can be run but I have not yet had any success exporting environment variables.
CONFIG_FILE="My Config File"
export CONFIG_FILE
I have also seen that some people have had success using PlistBuddy to write the values into the info.plist file during the pre-build phase of the scheme. This may be an option as well although it would require I redo a lot of my build process. I wanted to see if there was any other options before heading down this path.
Thanks for the help.
I was able to do this by using a .xcconfig file that is updated during my pre-build action in my scheme.
I used this tutorial to learn how to set up the project: http://www.jontolof.com/cocoa/using-xcconfig-files-for-you-xcode-project/
From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".
At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.
After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.
Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.
I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.
So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".
So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(
Edit: Here are 2 screenshots to illustrate the issue
First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.
Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.
As you can see, the framework linked with the code is not the framework in the project.
it seems problem with binding in new framework, your project still linked with old framework files.
try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path
Then after Drag and Drop Your "custom.framework" files in project.
it works for me.hope it resolve your problem.
Please try to clear derrived data:
Window -> Organizer
at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.
I guess it will solve your problem.
It might sound silly, but sometimes restarting XCode or the whole machine fix things.
Did you remove the old framework from Build Phases --> Link Binary With Libraries?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.
So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.
Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.
It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.
Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>
So you will check at least those 6 stages again:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)
Is my Folder Structure correct?
At least 1 to 4 must be right otherwise it will fail.
Here a random list of common causes
Framework is located outside your Source Paths structure
Structure got changed after you added it to the project
You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.
The Linking works, embedding works, but compiling does not. The Header information is still missing.
The solution must be to correct your Build Settings.
As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.
Erasing Derived data?
Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.
Correcting Linking?
Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.
But it is not wrong to start fixing first with
Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.
When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.
Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.
Needless to say that a Release Build likely needs another entry ending in "/Release".Hint: Well you can have different Search Paths for different Compile Schemes..
This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.
How to know if leading /../ will fix it?
Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.
Sorting of Framework Search Paths
play a role of course, just the same as #import/#include rule sorting matters.
Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules
#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif
So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.
My application's Info.plist file has around 20/30 keys inside. An external SDK we're implementing requires its app key to be set in the Info.plist, but requires separate keys for debug, enterprise distribution, and release schemes.
Is there a way I can create conditional additions to the Info.plist without having to maintain three duplicates of the file (and duplicate all of the other keys, which are identical across all targets)?
Basically what I'd like is the base plist exactly as it is now, then additional new -Debug, -Distribution and Release ones, which just contain this new key. What I'm trying to avoid is repetition of all keys, since it will make adding new ones in future a hassle.
Is this possible?
There are a few different things you might try.
Xcode run script executed before app build
This is a script that is automatically executed before you build. Let's say the 3 duplicate plist files are called InfoA.plist, InfoB.plist and InfoC.plist which are all exact duplicate. When you build the project the contents of InfoA.plist are duplicated to InfoB.plist and InfoC.plist. This would require some knowledge of writing a shell script to do that, but the script is fairly simple.
You could duplicate and rename the files in the script. Or you could use command line tools to copy the contents of the main file to the duplicate files. Two command line utilities you can use to modify the contents of plist files are plutil and https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/PlistBuddy.8.html. These links might help: Add files to an Xcode project from a script?,
Modify scheme and add pre-action
Your schemes also allow you to add pre-actions to your build and you can do the same as above, but have it configured as a pre-action instead of a build phase script.
Here are a few links that might help: how to make xcode run a script before dependencies?, https://www.objc.io/issues/6-build-tools/build-process/, Xcode: Running a script before every build that modifies source code directly but you could also google for “xcode run script before build” for more links.
I've got a relatively large Xcode project that produces a single app. However, I have many clients/customers who require deep customization and branding of said app. These configurations include different graphics, a few different interfaces and implementations, and, perhaps most importantly, .xcconfig files.
My Xcode project has a dedicated group that points to a particular client's customization folder on disk, so by opening the Xcode project and building, you get a build of the single app with the current client's customizations. To switch to another client, I change where that group points to on disk. (I also change and switch-back the xcconfig "Based On" settings in the project's Info pane to reload the full xcconfig inheritance; Simply changing the group containing one or more xcconfig files doesn't reload this!) This has worked great for 100+ clients. It's a little tedious to switch this folder every time you need to build the app for a different client and ensure the xcconfig is correct, but it works.
Now I'm in the process of automating builds via the command line, and running into troubles. The quick and dirty solution to pointing the aforementioned Xcode group at a different customization folder was to copy the ProjectName.xcodeproj/project.pbxproj file to ProjectName.xcodeproj/project-template.pbxproj and put placeholders inside this file that can be grepped and replaced with the name and path of the desired customization folder. Then, temporarily overwrite project.pbxproj with the modified project-template.pbxproj, and build to get the correct app.
As you've probably observed, the project.pbxproj was duplicated and modified, and will therefore get out of sync as developers modify the original and forget to also update the template. And besides, I shouldn't really be messing with pbxproj files in this fashion anyway -- that's Xcode's private stuff.
So, is there a better way to tell Xcode about a folder full of resources, code, and config files perhaps during the Build Phase with a script or environment variable, rather than at the project group level? The most complicated bit seems to be the xcconfig chain, since each client has their own xcconfig file that inherits from the single app's Debug, Development, and Distribution xcconfig files.
Sorry for the long-windedness of this question, but it's a little complicated! Any suggestions would be greatly appreciated!
I think you would way better off using the targets feature in Xcode. Have one project and the resources of every clients in that project.
You can then duplicate the target you already have (right-click on your target, by selecting the project file in Xcode's Project Navigator).
All your targets will be compiled with the same code. You just need to change the resources in Build Phases > Copy Bundle Resources to have different app created for each target. No need to look at Xcode's internal files.
You can even change the code in your source files by adding a preprocessor macro in your build options (something like FIRST_CLIENT=1) and then look for these definition in your file with #if FIRST_CLIENT.
I have a project set-up like this and it works pretty well :
There are bunch of helper filess in 'iPublicUtility' folder of several audio related Apple sample codes, such as aurioTouch:
http://developer.apple.com/library/ios/#samplecode/aurioTouch/Introduction/Intro.html
I can build these samples fine. But whenever I create a new project for testing and include the files from 'iPublicUtility' folder, I get:
'CADebugPrintf.h: no such file or directory ... ' error in 'CADebugMacros.h' file.
I made the settings of my test project to coincide with Apple samples, but this error is
not going away. Any suggestion?
SDK: iOS 4.2,
iMac OSX 10.6.6
Thanks all.
sy
select the Target, open the Build Settings pane, search for "Preprocessor Macros". Leave the fields blank (I've got rid of a DEBUG entry)
I used the answer provided by Justin and it worked fine, until I installed Xcode 4.3.1 and the problem came back.
Currently I solved this by downloading CADebugPrintf.h and .cpp.
I found the 2 files at this link:
http://svn.perian.org/trunk/CoreAudio/PublicUtility/
Cheers.
i have three distributions of Xcode installed.
the file exists in all three.
1) verify that the file exists on your system.
2a) add a search path to your project for the PublicUtility directory
or
2b) add the header to the target's "copy headers" build phase
depending on how many depends you have for these files, you may want a more reliable approach (which exists). one (fairly) safe/easy way to do this if you use a lot of the audio technologies and sources is to add its parent dir's parent dir to your search paths or source trees (recursively).
another way is to add it to a shared build settings file.
you could also copy a specific release someplace, then add that to your search paths. just be aware that the sources get updated somewhat regularly, so you'll have to update it when it's a good time for you. in this case, you'll should change your project references as well.
Edit: Adding the search path (2a)
One way to add a search path (assuming Xcode tools are installed at : /Developer/):
1) In Xcode (3), select the target.
2) cmd+i (get info)
3) select the "Build" tab of the info window
4) enter HEADER_SEARCH_PATHS into the search field
5) if the value is not defined at this level (e.g., it is not bold), then set the value to /Developer/Extras/CoreAudio/PublicUtility/ $(inherited)
if it is already defined at that level, then add /Developer/Extras/CoreAudio/PublicUtility/ to the list of directories to search (the value).
if you want to search the library recursively, use /Developer/Extras/CoreAudio/**. this may be useful when building AUs, or other projects which require the AU includes and PublicUtility includes.
Same problem, but seemed to have fixed it by downloading from the link below and adding in the missing CADebugPrintf.h and CADebugPrintf.cpp files.
https://developer.apple.com/library/ios/samplecode/CoreAudioUtilityClasses/Listings/CoreAudio_PublicUtility_CADebugPrintf_h.html
I was having the same problem and downloading the files into the iPublicUtility folder did not solve it. I found the answer by accident while learning about .mm extension files on this page:
Objective C Project using C++ POSIX Classes
I renamed my implementation file with a .mm and the compiler errors disappeared. Hope this may help someone down the line!