Re: Advice request on Xcode configuration for long term project.
Re: Advice request on Xcode configuration for long term project.
- Subject: Re: Advice request on Xcode configuration for long term project.
- From: "email@hidden" <email@hidden>
- Date: Thu, 3 Dec 2009 18:18:41 +0000
On 3 Dec 2009, at 16:56, Xochitl Lunde wrote:
>
> I am working on a software product which has about 45 libraries and 3 main executables that utilize the libraries. I am compiling the product on Mac OS now using the automake tools like I do on Linux. I am considering changing over to using Xcode for the Mac platform, but I want to make a good decision on how to setup Xcode. My main problem is that I have written a configure.ac that checks the Mac for a bunch of different headers and defines macros if present. I also have features like enabling SSL and SNMPv3 in my codebase. I need to retain the settings that I get from configure in a manageable way. It is also pretty nice that configure tests which headers and even functions are available to me on the Mac.
>
> I do not care if I have to use the command line to do builds, although it might be convenient if Xcode did the builds. I do care that I am able to generate a nicely installable .app package/folder for eventual distribution to Mac users. Right now my make installs into /etc like it would on a Linux system. I also need to use the debugger from Xcode.
>
> I can setup my Xcode in a couple of ways:
>
> 1 giant project with multiple static / dynamic library targets and 3 executables
Xcode has no trouble working with multiple targets in this way. If gives the best flexibility as you can freely move code between targets as and when required.
The build system is very powerful.
> 45 tiny projects with just one static / dynamic library target and 3 projects which reference targets from the 45 libraries (I got Xcode to build one of my libraries, but I had to copy the settings from config.log into the target build rules individually.)
My app includes 6 separate sub projects and 22 targets that builds 3 executables and a load of plug ins, importers etc.
Having separate projects can be useful for things like mdimporters and certain frameworks.
It's most useful for incorporating pre-existing projects into your code.
I don't think I would particularly want to handle 45 of them though.
> 1 giant project with multiple External build tool targets to run Make in my individual library folders and 3 executable targets, which also basically run make. (I am really clueless on how I would set this up to create a nice *.app for me though)
Not really making the most of Xcode's feature set.
> 45 tiny projects which run External Build tool targets for library builds and 1 or 3 projects which create my final executables by running make. ( I have another project setup like this and it does work, but I have to do configure separately and make install separately.)
> An organizer project to run my makefiles (but I would like to have codesense)
> 1 External Build System project that just runs make at the top level.
>
> Getting Xcode GUI debugger visibility into all my code is my #1 priority. Being able to create a nice installation package is my #2. CodeSense is desirable but not required. I'm very comfortable with autotools so it's not a priority to replace the build system completely with Xcode unless it happens to be a lot simpler. I do not intend to xcompile for other platforms.
>
You can attach xcode to a running process. If the process contains debug symbols it will permit debugging.
> Any thoughs or advice on this decision would be greatly appreciated. Thank you.
>
> Xo
> _______________________________________________
> 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
_______________________________________________
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