Hi Stephane,On May 26, 2010, at 6:23 AM, Stéphane Beauchemin wrote: Hi Everyone, We have a bunch of static libraries that need to be compiled on OS X. Currently all the libraries are managed in Xcode projects. Almost all of our code is cross-platform (running on windows and gaming console); so our IDE of choice is normally Visual Studio but except for mac OS X. My colleagues are having hard time with the XCode projects : they say that XCode project don’t play nice with SVN... which is true. Sometime you make small modifications in Xcode project and you and up with huge differences when doing a diff with old version of the project. I know that Xcode project are in xml but it doesn’t seem possible to edit files by hand since Xcode add an ID next to each item.
Xcode makes some strange and seemingly useless changes to the project files. It seems to add/remove comments in the pbxproj file, just because you opened the project in Xcode. I always end up reviewing those changes in the SVN client we use, and often I just revert the change before I check in so that when others update they don't rebuild everything. But that's probably bogus, because when they open the project Xcode probably makes the same changes and, I expect, the project file changes trigger a rebuild. But I don't know that.
Another problem with Xcode project is that they can’t be edited on a windows computer. The dev that adds an object to a library need to walk to a mac, open the Xcode project make the changes and commit (we haven’t found any good remote desktop application for remotely access a Mac from a PC).
For those reasons, we are thinking of switching to using makefiles. Makefiles can be edited with any text editor and it is easy to see changes you have made to it. Going back to makefiles seems a bit dumb when you have a tool like Xcode, but it seems the only solution. I am sure I am not the only one out there hitting problems like this. Any thought, suggestions?
We do Mac/Windows development, but we mostly start with a Mac Xcode project, then create the Windows project/solution. We have found that it is very easy to edit the VCPROJ files by hand, so that's the way we usually create a new project. It's much harder to edit a pbxproj file because everything is referenced by GUID, not to mention that the format is undocumented.
You have probably 3 good options if you want to use Makefiles: 1) Just use bare make and maintain the Makefiles by hand. 2) Try to use cmake and either use it directly or have it write Xcode project files for you. Then you can edit the cmake source to add/remove files, etc. I have never used cmake, so can't comment on the usefulness of this idea. 3) Get the free version of Qt from Nokia and use their propject management tool. It knows how to write Xcode project files and Makefiles. I believe you could use it without getting tangled up in a bunch of Qt-related issues. The advantage is that you just edit a text file to add/remove files and build options.
You could also use Xcode Makefile targets, but the Make support in Xcode is not great. If I were going to use Makefiles for all my static libs I'd rather develop a really good Makefile template by nhand and just use command line make.
The downside of switching to Makefiles is that you lose all the build configuration goodness that Xcode provides. The pane where you set the build settings knows much more about the Mac than you do, and knows how to set some fairly obscure compiler and linker flags, and knows about new obscure flags that APple dreams up in new compiler versions. We even make Xcode projects for our third party libraries that we could build via configure/make, just because Xcode knows about all those compiler settings, and we can easily make triple-architecture static libraries for, say, boost or libxml or whatever other library we use.
You can also script the build settings by using Xcode config files. We have a base project config file, then a family of target-specific files. So when we make a new static library project, we bring our config files into the Xcode project by adding them to a Cnfiguration Files folder. Then we set the project build settings to be based on ProjectRelease.xcconfig or ProjectDebug.xcconfig and we set the static library target to be based on TargetStaticLibRelease.xcconfig or TargetStaticLibDebug.xcconfig. That takes care of all of the build settings and all of the static libraries get built the same way. (Since we made our Xcode projects first, then went to Windows, we do the same thing there with inherited property sheets. The top level library project just inherits StaticLibRelease.vsprops or StaticLibDebug.vsprops.) If you can move your configuration stuff into config files, then whay you mostly do is open the project and add existing files to it and it has a nice filter when you do that so you can only select files that aren't already in the project.
I think my bottom line is that you're better off sticking with Xcode projects. It takes some effort to understand how it works, and it's quite different from Visual Studio, but it's worth the effort in the long run.
Best regards, Rush
|