Xcode: An easy way to share build settings amongst several projects with multiple targets
May 16, 2008 @ 12:16
Pose you’re working on an application that is divided in multiple Xcode projects. These setups are quite common in cross platform development, where you often have one project for each logical part of the application. Let’s assume that we’ve got the following parts:
- Foundation(.xcodeproj)
A simple library with OS dependent implementations of threads, file system manipulation functions etc. Each class here inherits from an OS independent interface. - Controller(.xcodeproj)
The heart of the application. This consists of OS independent logic that connects the different parts of the application - Interface(.xcodeproj)
The interface that communicates with the controller
Let’s assume that you want each of these projects to treat all warnings as errors. How do you go about to perform that? One way would be to open up each project in Xcode and open up the project info window for the project in question. Then, under the Build tab, you’d scroll down to GCC 4.X - Warnings and enable Treat Warnings as Errors. That’s nice! Now all warnings are treated as errors - definitely worth a minute or two!
Now, when building one of the targets in the Foundation project, you notice that you do indeed still get warnings, even though you told the Xcode project that you wanted to treat each warning as an error. Huh? How come? You start scratching your head, once again re-opening the project info window to make sure that you really enabled the setting. And aaaah! You notice that, under the Build tab, the Configuration setting isn’t set to All Configurations but rather to Debug. Flipping it over to All Configurations you notice that the setting in question differs between the various configurations in the project; the Release configuration still isn’t set to Treat Warnings as Errors. Fixing it, and everything once again works as you intended it to do.
Now, that took quite some time to get right, didn’t it? And it was kind of error prone too, right? Wouldn’t it be so much simpler if you could make these kind of settings in one place instead? Well, there is; enter the wonderful world of the xcconfig (Xcode Configuration Settings File) file format. Want to see how it can be used? Take a look at the Xcode User Guide: Build Configuration Files and start enjoy your life as a Mac developer again… :)
GCC 4.2: Let’s treat some warnings as errors
May 1, 2008 @ 10:57
Along with GCC 4.2 came a feature that I didn’t know about until Tommie at work revealed it for me yesterday (below snippet taken directly from GCC’s online documentation on warning options):
-Werror=
Make the specified warning into an errors. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. You can use the -fdiagnostics-show-option option to have each controllable warning amended with the option which controls it, to determine what to use with this option.
Fantastic! I’ve been waiting for something like this for ages (since some warnings are quite evil, telling you that a certain function call will abort at runtime). Now you can tell the compiler to simply stop compiling if it encounters a “problematic” warning.
Featured articles
- RSS feeds - the hidden gems of delicious
(December 28, 2008 – No Comments) - Command of the day: nl
(December 18, 2008 – No Comments) - Ain’t no language high enough
(December 17, 2008 – No Comments) - Google Mail / Safari: Stealing focus when loading is complete is not OK
(December 7, 2008 – 1 Comment)