Re: From GNU autoconf/automake to Xcode 2.3?
Re: From GNU autoconf/automake to Xcode 2.3?
- Subject: Re: From GNU autoconf/automake to Xcode 2.3?
- From: Syd Polk <email@hidden>
- Date: Wed, 5 Jul 2006 09:42:18 -0500
On Jul 5, 2006, at 9:07 AM, Bilhanan S wrote:
Hello,
I just installed Xcode 2.3 in my Powermac G5, and I could not find
any kind of information as to whether I'm on the correct track or not.
I have a rather large C++ project which I'm contemplating moving to
using XCode. At the moment, the project uses the GNU autoconf/
libtool system (./configure, make, make install) with a small
wrapper script that allows you to specify your C++ compiler of
choice as well as the build location.
The upshot of it is that currently, the project has a fairly well-
defined directory structure, a CVS repository and several binaries
and shared libraries as a result of the build process. None of it
is Mac OS X specific.
I'd like to know if I'd encounter any difficulties migrating this
project to use XCode? Would I need to sacrifice any of the above?
I've gone through some documents about project migration to XCode,
but they only seem to involve CodeWarrior, and appear to support 1
target build.
If this is the wrong list to ask this question, I apologise :-)
regards,
Bill
If everybody else using your code is using Xcode, and you don't have
to maintain some kind of cross-platform compatibility (i.e., you will
only run on Mac OS X), then moving to Xcode completely might make sense.
If, on the other hand, this is an open source project, and is
intended to support multiple platforms (and if it is autoconf-
iscated, I would be that both of these assertions are true), you are
going to want to just "wrap" the project with Xcode (and maybe not
even do that).
The basic recipe for moving an autoconf-iscated project to Xcode
completely:
- You are going to have either run configure once to generate
config.h for all of the #define statement it leaves behind, and put
each of them in build settings by hand.
- You are going to have manually recreate any weird dependencies in
your makefile in Xcode's build system.
- If your build system does anything besides compile, assemble,
invoke lex/yacc, and link, you are going to have to take everything
else and put them into shell script build phases.
- You are going to have to take every compile flag you use and stuff
them into the Xcode build system someplace. The easiest thing to do
is just copy the values of CFLAGS and CXXFLAGS into the appropriate
variables in the target; however, you won't see them reflected in the
GUI. Since these are kind of hidden inside of configure, you are
going to have to build your project with configure/make, and see what
your build output generates.
- Everything that is done normally done by the install target will
have to be reproduced into Copy File or Shell Script build phases by
hand.
- Once you get done, you will probably have to create custom
executables for your binaries so that you can debug. And you will
probably have to fiddle with build settings to get the debugging
symbols right. And the executables live in your xcode user file, not
the project file. To share all of the custom executables, you need to
set them all up, copy and rename your user file to
"default.xcodeuser" (I think. The basename needs be "default"; the
extension should remain the same).
- If others working on this project are not in Xcode, any changes to
project structure (adding files, removing files, changing
configure.ac, changing Makefile.in, etc) will have to be updated by
hand, adding or removing the files to the project and going through
the above steps.
Ugh. There is only one really good benefit from doing all of this in
my mind; building Universal can then be done by simply checking the
Intel box, and fixing all compiler and link errors, and debugging.
There might be some cleanup of build settings, setting SDK values,
etc, but that would be true of any port.
A slightly less ungainly way to use Xcode with an autoconf-iscated
project is to "wrap" the project using Xcode. (I personally have done
this with gcc. The above is just too much work for gcc considering
how complex it's build system is and how much daily churn there is on
the source tree).
- Instead of importing your source directly into Xcode, set up a
folder reference to the top level directory of your source.
- Create a legacy makefile target.
- Create a shell script build phase which runs configure in $OBJROOT.
- Make the makefile target run the make in the $OBJROOT directory
that was generated by configure.
- Make a custom executable that runs the binary generated by make.
BTW, this is how Tcl/Tk builds on Mac OS X.
After fiddling with this a while, you should be able to get Xcode to
build, run and debug your binary. However, there are gotchas:
- You still have to run the shell script build phase separate from
your make phase, since you normally don't want to rerun configure.
However, you have to fiddle with dependencies a lot to get configure
to run automatically.
- While folder references are work and can be handy, they are also
quite fragile, and can be slow for large projects (like, say, gcc),
- You still have to hack configure/make to make universal binaries,
sometimes significantly. Unless your project is distributed via
source (you never ship binaries), this can be significant, especially
if you want to support PowerPC versions of Mac OS X earlier than 10.4.
Still, this method is tolerable for a project which does not actually
change that much.
In general, for a project that is medium-size or larger, and that
actively supports another non-Mac platform, I would not bother
putting it in Xcode, and would do all of the work of getting to build
universally by hacking configure/make, either by passing multiple
arch's to the compiler/linker, or by building for each arch
separately and calling lipo. While it may seem like more work up
front, it's not, really, and is much more maintainable over time.
Personally, I do this, and just use Xcode to edit text files.
Syd Polk
email@hidden
"Let the music be your light" - Dave Edwards, KUHF-FM, 1982
_______________________________________________
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