Can we set the build settings for different targets in the project build settings in xcode?
Yes, just select the target, get info, and change your build settings. You can get-info on the project to set global settings, get-info on individual targets to make things more specific, and change configurations (debug/release/etc.) in both areas for build specific behaviors.
Related
In the settings for CLion, CMake only appears in Build, Execution, Deployment under project specific settings. It does not exist under Default Settings. Is there a way I can specify a universal CMake configuration such that it is available to all projects by default for current and all future projects unless specified otherwise?
For example let's say I want to set the Generation path of all projects to a default location of build. Instead of manually editing the project settings for each project to include that, is there a workaround to set that as the default?
Please try to provide a solution that will only affect a local environment
Only starting from CLion 2019.3 there is ability to configure CMake defaults.
It will affect all new projects (without .idea config directory).
You can specify default build types/toolchains, CMake options, generation path etc.
Also there is pretty nice macro $PROJECT_NAME$.
I have a #if in a project that depends on which build configuration is selected (eg: Debug, QA, and other test environments). When a user changes the build configuration in VS2015/Xamarin Studio, I need the IDE to force a rebuild on this project when the user builds the solution. How do I do this? At the moment, rebuilding the solution will reuse the compiled dll's.
In other words, how do I set a project dirty after a user changes the build configuration to force a rebuild.
Make sure the Output path of the project is unique to the build configuration. Otherwise MsBuild will just compare the timestamp of the input files and the existing output files and will conclude that a rebuild is not required.
It is assumed that when two projects build a different configuration, that they also write to a different folder for this reason.
Normally the output location is set to .\bin\$(configuration) to ensure this is the default behavior.
I have just set up three different configurations in my project for debug preview and release. No in Xcode there is an option to specify different .xconfig files per configuration. I am now wondering in what circumstances they should/could be used and what their advantages are over just editing the build settings per configuration.
Use xcconfig files if you find yourself changing the same build settings for each project you create. Place the build settings you're changing in the xcconfig file. By using a xcconfig file you can avoid editing those build settings every time you create a project.
Having the option to use different xcconfig files for each build configuration allows you to place the debug build settings you're constantly changing in one xcconfig file and place the release build settings you're changing in another xcconfig file. Use multiple xcconfig files if the build settings you're changing have different values for debug and release builds or if you change some build settings only for debug builds and other build settings only for release builds.
It's not me who you asked about an example #Besi but I would like to explain why the BundleId change is useful at least for me.
When I have different requirements for "Development", "Ad Hoc", "App Store", for example I need to send Push Notifications, so the push certificate will be different depending on the version.
In this case I can make 3 different XCode schemes and depending on the chosen scheme, when compiling the bundle identifier will change so a different kind of version will result.
Add to this the fact you can use you xcconfig to choose the "Code Sign Identity", and practically every build setting you can imagine. This way is more correct than having different targets for each version and with different plist files and build settings, because you avoid duplication and you can customize the way the settings should override each other.
Sorry if this is very convoluted, I tried responding the original question in the process.
One way I've used xcconfig files is to set up different BundleId's for iPhone apps. That way you can have different apps with different features/servers enabled. Very helpful. It involves using a variable name for the BundleId.
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.
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.