Re: managing xcode projects vs going back to makefiles
Re: managing xcode projects vs going back to makefiles
- Subject: Re: managing xcode projects vs going back to makefiles
- From: Xochitl Lunde <email@hidden>
- Date: Wed, 26 May 2010 17:06:22 -0500
<xcode-users-bounces+xochitl_lunde=email@hidden>
wrote on 05/26/2010 01:39:20 PM:
> On May 26, 2010, at 8:23 AM, Stéphane Beauchemin wrote:
> > 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).
It's probably inappropriate for your environment,
but just incase, my www.logmein.com Mac OS client works great for remote
desktop to my Mac from a Windows IE browser.
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.
Did you try setting the MIME type in SVN configuration
on Mac OS? SVN should figure it out by itself, but I always set it explicitly
on my Macs anyway.
From Xcode 3.0 Unleashed ISBN 13: 978-0-321-55263-1
Open ~/.subversion/config
Enable the global-ignores setting by removing leading
# character. Append additional file types: *~.nib *.so *.pbxuser
*.mode* *.perspective*
Turn on autoproperties by uncommenting "enable-auto-props
= yes"
In the [auto-props] section, add
*.mode* = svn:mime-type=text/X-xcode
*.pbxuser* = svn:mime-type=text/X-xcode
*.perspective* = svn:mime-type=text/X-xcode
*.pbxproj* = svn:mime-type=text/X-xcode
Could something similar help on Windows?
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?
My project was in C++ using Makefiles from automake.
I once tried to use raw make to build a 3rd party library, but I
ended up having to create my own autoconf input files and automake input
files to get something that ended up being compiled for my architecture.
(I've never tried cmake before, that might be just fine.) I've
converted all my builds to Xcode builds, and I am much happier with it
except that I haven't figured out how to use CPPUNIT for unit testing.
Using Xcode also makes it much easier to build for
multiple architectures of Mac and create the fat binary. The fat
binaries were the only part of using autotools which looked like it could
become a real 'gotcha' for building my project. If you don't need
to do this, then maybe you will be able to get away with using Makefiles.
I didn't get to the point of trying to manage debug vs. release versions
using autotools, though.
When I was building using Makefiles, I had to keep
a separate updated Xcode project to use for debugging. I had to add
all the same files to the Xcode project so that they would be viewable
in the debugger. Even if you switch to using Makefiles, how are you
planning to debug effectively on Mac OS? If you're going to keep
using Xcode as your debugger, then it seems like you'd be doing twice the
work to switch to Makefiles.
Right now, I am the only Mac developer, so basically
everyone breaks my build and then I have to look at the diffs and fix my
Xcode build. Since we are a small group and my colleagues and I all
have different platforms (I don't have an OpenSUSE or Fedora 8 or 64-bit
Windows), we all just agreed to fix the build as it affects the platforms
we have access to. This is not as good as how Dan's team does it,
but it seems to save everyone the trouble and time of having 17 computers
at their desk + the cost of having an embedded station. We make sure
it builds for everyone at intermediate checkpoints. (Not saying you should
do this, but I'm just explaining the situation relative to my perspective)
A final note, this mailing list is extremely active
and helpful to me. I received much more support and help when using
Xcode than people were able to give me when using makefiles. Although
the list was certainly helpful when I used Makefiles, there are so many
more people who know Xcode who can help out when you have an Xcode specific
question.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden