I'm using bison parser generator in my Xcode 4 project. I've written custom build rule for generating C++-source file from *.y grammar file:
/usr/local/bin/bison
--defines="${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.hpp"
--output="${DERIVED_FILES_DIR}/${INPUT_FILE_BASE}.cpp"
--verbose "${INPUT_FILE_PATH}"
As you can see, Xcode places generated files in $DERIVED_FILES_DIR folder. Now I need to export generated header file grammar.hpp with object files as library.
The problem is that Xcode doesn't allow export files, that aren't included in project.
The first solution, as it seems, is to create a group with absolute path set to $DERIVED_FILES_DIR. Well, it actually works until I change my build settings to build Release configuration, since $DERIVED_FILES_DIR is dependent on build settings.
The second solution is somehow set group path to literally variable, i.e.
path = $DERIVED_FILES_DIR
So far I've found two possible ways to do it: How to reference files with environment variables? and File references relative to DERIVED_FILE_DIR in Xcode. Either way doesn't work for me.
Maybe someone knows better way to add generated files to project?
Your best options are:
Generate the files in your SRCROOT
Generate the files in BUILT_PRODUCTS_DIR
These both have "Relative to..." options that should allow you to add the files to your project.
I ended up generating files in ${SRCROOT} directory with custom make build target using Makefile that handles regenerating derived files. I just added these generated files to project, and made all actual build target depend on this make target.
Related
I like to have the project file untouched unless I make an active decision to add something, so I create the project file using make.
The first instance of the project file is created by quartus_map and I can later add pin declarations etc using quartus_sh.
But I have not found a good way to add an IP block, qip-file, to the project in time since quartus_map need all files to be available.
How can I solve this?
I'm currently using:
quartus_map project_name --analysis_and_elaboration --family=... -f sourcefiles.args
It will not help to add it in the list of source files...
I'm using git-svn and I'm trying to embed my revision number into my iOS app. At the moment, I have a build phase which runs the following script:
SVN_REVISION=$(git svn find-rev HEAD)
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $SVN_REVISION" "$INFOPLIST_FILE"
The problem with this is that, since the repo always contains the previous revision, the script always makes my Info.plist dirty.
Is it possible for me to dynamically set my app's build number without dirtying my source tree?
1) Add a new target to your project of type "Aggregate", e.g. you may name it "Update Info.plist Prefix Header"; just use that as "Product Name" in the dialog.
2) Add a Run Script build phase to this new target with the following source code:
#!/bin/sh
SVN_REVISION=$(git svn find-rev HEAD)
echo "#define SVN_REVISION $SVN_REVISION" > "$SCRIPT_OUTPUT_FILE_0"
3) Add an output file to your script, name it
$(CONFIGURATION_TEMP_DIR)/InfoPlist.pch
4) Open the Build Phases of your iOS app.
5) Add the aggregate target you created before as dependent target (add it to "Target Dependencies"). This means Xcode will always first build this target before it will build your iOS target.
6) Open the Build Settings of your iOS app.
7) Search for the setting "Info.plist Preprocessor Prefix File" and change it to exactly the same value you used for the output file in step (3).
8) Search for the setting "Preprocess Info.plist File" and make sure it is enabled.
9) Open your current Info.plist file and change the value of CFBundleVersion to SVN_REVISION. Do not use $(SVN_REVISION) or ${SVN_REVISION}; this is no build setting or environment variable replacement, this is a preprocessor replacement, so just use SVN_REVISION.
That's it. Each time you build your iOS app, Xcode first builds the aggregate target, which updates the PCH file, and when it builds your iOS app, it will run the Info.plist file through the C pre-processor (using the PCH file as prefix header) before copying it to your application. The pre-processor will replace SVN_REVISION since it is defined as a macro in your PCH file.
Important Notes
Some people may think it is a better idea to use $(DERIVED_FILE_DIR) instead of $(CONFIGURATION_TEMP_DIR). Well, in theory they are right, yet there is just one problem in practice: The derived file dir is different for every target, while the configuration temp dir is the same (it is only different for every build configuration). When using derived file dir, the PCH file is written to the derived file dir of the aggregate target, yet when building the iOS app, Xcode will search for this file in the derived file dir of the iOS app and thus it won't find the file.
Some people may also think it is a better idea to just add the Run Script phase that updates the prefix header as the first build phase of you iOS app instead of creating a separated target for it (this would also resolve the derived file dir issue mentioned above). Again, nice idea in theory but cannot work in practice: If preprocessing is requested, the Info.plist is preprocessed before the first script phase is even executed, so if the PCH file does not exist already or has not been updated already, either the build terminates with an error or an outdated SVN revision is written to the plist file. That's why you need a separate target for this task that is guaranteed to be build before your actual target is.
Mecki thank you for the excellent answer! I applied the same concept to set a version timestamp and the current git SHA for the build.
FYI I just ran into a small issue. It seems that, at least in Xcode 5, if you specify an output file the script step uses it as a cache, so no matter the changes I made to my actual app code the script reported that it had ran but the values were not the current ones...
I had to move the output file declaration to the script itself to solve the issue, i.e. added
SCRIPT_OUTPUT_FILE_0="$CONFIGURATION_TEMP_DIR/InfoPlist.pch"
to the top of my script.
Additionally the original plist should also be touched in order for the build step to copy the new values in, so I also added
`touch $SCRIPT_INPUT_FILE_0`
after the previous output file declaration. This touch operation does not make git detect the change as commit-able.
Cheers
So frustrated with XCode right now. I can build and run from code perfectly fine. However, trying to archive is a disaster.
I created a project, then dragged the .xcodeproj into XCode on the project navigator. Shows up fine, cool. Parent project build settings:
Other linker flags: -all_load, -ObjC
Target Dependencies : CocoaLibSpotify (subproject I'm incorporating)
Link Binary with Libraries : libCocoaLibSpotify.a
When I build my project, the following lines work
#import "CocoaLibSpotify.h"
#import <CocoaLibSpotify.h>
However, when I archive, my project fails to find these files. It's worth noting that the subproject files aren't in the same directory as the parent project. However, isn't that the point of the target dependency/link binary with library? Why is it failing to archive? This seems like it should be a lot easier than it's being.
Thanks.
Edit: Errors from compiling
In file included from /Users/ericharmon/Projects/teamsync/teamsync/TeamSync/AppDelegate.m:12:
In file included from /Users/ericharmon/Projects/teamsync/teamsync/TeamSync/Classes/GUI/ViewControllers/LoginViewControll er.h:9:
In file included from /Users/ericharmon/Projects/teamsync/teamsync/TeamSync/Classes/GUI/BaseViewController.h:10:
In file included from /Users/ericharmon/Projects/teamsync/teamsync/TeamSync/Classes/Model/Managers/Managers.h:9:
In file included from /Users/ericharmon/Projects/teamsync/teamsync/TeamSync/Classes/Model/Managers/AppLogicManager.h:11:
In file included from /Users/ericharmon/Projects/teamsync/teamsync/TeamSync/Classes/Model/CoreData/CoreDataObjects.h:13:
/Users/ericharmon/Projects/teamsync/teamsync/TeamSync/Classes/Model/CoreData/Track.h:13:9: fatal error: 'CocoaLibSpotify.h' file not found
#import <CocoaLibSpotify.h>
^
1 error generated.`
Archive uses a different directory structure when building, which can be a pain. I've found success by adding the following to the User Header Search Paths build setting of your application's target:
"$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include" (including the quotes).
Also, make sure Always Search User Paths is set to Yes.
In addition, I have $CONFIGURATION_BUILD_DIR/include in my Header Search Paths setting, but I don't think that'll help archiving.
Background: I'm using CMake to configure a project that builds a combination of libraries and applications. Each application uses resource files such as images and text files that are unique to that application. Xcode understands the concept of resource files and can correctly copy them into the application bundle. If I were creating a project with exactly one application, there would be no problem: I can use CMake's set_source_files_properties(... PROPERTIES MACOSX_PACKAGE_LOCATION Resources) to tell Xcode to put the files into the bundle's Resources directory, such that a later call to [[NSBundle mainBundle] pathForResource:...] will correctly find them. (The pathForResource method searches the "Resources" directory by default.) The files also appear in the Resources group within the Xcode project.
Question: The problem appears when I include multiple applications in the CMake project. Each project needs to copy its own, distinct resource files into its own bundle's Resources directory. Therefore each application needs a distinct Resource group in Xcode in which to hold these files and from which to copy them. Yet these distinct directories must all be named "Resources." Ideally, each application-specific folder within Xcode would have its own unique "Resources" subdirectory with all of its needed resources. What actually happens is that the project has a single, shared Resources directory into which all the resource files are collected, and the project-specific "Resources" subdirectory contains only that application's info.plist file. Because all applications' resources are tossed into the same group, and because name collisions can occur (two projects with distinct files that have the same name), project bundles don't get the correct resource files.
Has anyone found a way to use CMake to setup an Xcode project that supports multiple applications with distinct resources? Or some other workaround?
My solution works for me but maybe this is not satisfying for you.
What I do is a simple copy files post build step where I copy my resources directly into the built Target.app.
The problem with my approach is that the files don't show up in the Xcode project.
Here is how I do it :
I override the ADD_EXECUTABLE macro. Inside, it evaluates the resource variable ${target}_RESOURCES.
So in my CMakeLists.txt for my target I collect some directories and resource files and store them as list in my target depending resource variable.
The following custom command is in my macro (could be anywhere, actually):
ADD_CUSTOM_COMMAND( TARGET ${target} POST_BUILD
COMMAND ${CMAKE_COMMAND} -DFILES_LIST="${${target}_RESOURCES}" -DDESTINATION="\${TARGET_BUILD_DIR}/\${FULL_PRODUCT_NAME}" -DEXCLUDE_EXT=".svn .git CVS .DS_Store" -P ${ROOT_DIR}/cmake/scripts/copyFiles.cmake
WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}
COMMENT "Copying resource files and directories to iOS App Bundle..." )
It calls my copy files script (Maybe there is a better way to add that custom build step):
SEPARATE_ARGUMENTS( FILES_LIST )
FOREACH( ENTRY ${FILES_LIST} )
MESSAGE( "copying: ${ENTRY} to ${DESTINATION}" )
FILE( COPY ${ENTRY} DESTINATION ${DESTINATION} PATTERN "${EXCLUDE_EXT}" EXCLUDE )
ENDFOREACH( ENTRY )
It works for me. I don't really care if the resources show up in the XCode project.
But I still would like to know.
Are there are any problems or issues when not having the files in Xcode?
I have an Xcode project with a large number of targets where I would like to include a settings bundle for apps built under the Ad-hoc and Debug configurations, but not under the Release configuration.
Build Phases don't seem to allow for making themselves conditional on configuration (they can obviously be conditional on target, but doubling the number of targets in the project would make it completely unusable).
That leaves writing a custom Build Rule. My plan is to exclude the Settings.bundle from all targets, and create a build rule that conditionally copies it into the product package, but applicable examples are really hard to find.
The build rule I've started has the Process setting set to "Source files with names matching:" and Settings.bundle as the name. The Using setting is "Custom script:".
My custom script is as follows (with the caveat that my bash scripting is on a cargo cult level):
if [${CONFIGURATION} = 'Debug'] then
cp -r ${INPUT_FILE_PATH} ${DERIVED_FILES_DIR}/.
fi
Finally, I have ${DERIVED_FILES_DIR}/Settings.bundle listed as an output file.
Since I'm here, it should be obvious that it's not working. My first question is whether there is somewhere I can view the output of the build rules as the execute to make sure that 1) it's actually being executed and that 2) I don't have a stupid syntax error somewhere.
Also, what's the proper location (in the form of an environment variable) to copy the output to?
I finally figured it out.
For each target for which you want to conditionally include the settings bundle, choose its Project from the source list, choose the target, and switch to the "Build Phases" tab.
Click the "Add Build Phase" button and choose "Add Run Script".
Then enter the following for the script:
if [ "${CONFIGURATION}" == "Debug" ]; then
cp -r "${PROJECT_DIR}/Settings.bundle" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app"
fi
I know this question has been answered already, and the answer was very helpful to me, but I wanted to throw my own modified solution out there as well.
My requirement was to have different settings bundles for different build configurations, rather than just not including it at release. Assuming a simplistic approach of only Debug and Release configurations, here's how to do it:
Start by adding 2 settings bundles to the project, named Settings-debug.bundle and Settings-release.bundle and then remove these files from the Copy Bundle Resources build phase. Next add a user defined build setting called SETTINGS_BUNDLE, which has different values for each configuration:
Debug ${PROJECT_DIR}/relative/path/to/Settings-debug.bundle
Release ${PROJECT_DIR}/relative/path/to/Settings-release.bundle
Next add a run-script build phase (after Copy Bundle Resources) named Copy Settings Bundle with a modified version of the script in Frank's solution.
cp -r "${SETTINGS_BUNDLE}/" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle"
The difference here is that the copied bundle is always named Settings.bundle regardless of the source name.
You then need to add another build phase script to prevent code signing errors when the only changes are in the settings bundles. It forces the code signing step to occur on every build. This should run before the Compile Source Files build phase. I called mine Force Codesign.
touch "${PROJECT_DIR}/relative/path/to/main.m"
For complied sources, there is a poorly documented user defined build setting that can be added. Files can be both excluded and included from compilation
Go to your target's Build Settings > Tap the + button > Add User-Defined Setting
The key is either INCLUDED_SOURCE_FILE_NAMES or EXCLUDED_SOURCE_FILE_NAMES
The value is a space separated list of file paths
See reference:
http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
(Tested with Xcode 9.3)
I can't find when Xcode included this feature but EXCLUDED_SOURCE_FILE_NAMES is now directly available in Build Settings > Build Options > Excluded Source File Names.
So you no longer need to create a User-Defined Setting.
See below:
It will automatically add this line in your .pbxproj.
Settings.bundle is always copied into destination area no matter whether Release or Debug configuration. So, maybe you need the following code:
if [ ${CONFIGURATION} == "Release" ]; then
rm -rf ${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Settings.bundle
fi
I am no shell script expert but I think you need space between the square brackets and the condition. Also, quoting the variables may help:
if [ "${CONFIGURATION}" = "Debug" ] then
cp -r "${INPUT_FILE_PATH}" "${DERIVED_FILES_DIR}"/.
fi
As for the location, I use "$BUILT_PRODUCTS_DIR"/"$FULL_PRODUCT_NAME" for the root of my OS X app bundle.