Wrangling 3rd party libraries with xcconfig settings?
Wrangling 3rd party libraries with xcconfig settings?
- Subject: Wrangling 3rd party libraries with xcconfig settings?
- From: Allen Cronce <email@hidden>
- Date: Thu, 20 Nov 2008 09:02:49 -0800
Hi all,
We make heavy use of open source third party libraries. For a variety
of reasons, we need to build static versions of these libraries. We
have scripts that help us build these periodically, by implementing
the usual configure, make, make install, rinse, repeat dance.
The problem with this approach is maintainability. Currently our
regular Xcode projects all share common project and target xcconfig
files. When we want to make a global change, like targeting a new base
SDK, it's in one place and is really easy to do. But the third party
library builds don't have access to our Xcode config settings. So when
we make fundamental changes, we have to manually monkey with the third
party configurations to match what we're building with the main
projects.
To make this process easier, we're trying a hybrid approach where
Xcode drives the configure and make process, similar to what this
developer did for sqlite:
http://ascarter.wordpress.com/2006/05/21/xcode-project-for-sqlite/
The difference in our case is that we're translating our Xcode config
settings to environment flags passed to a given open source library's
configure script. So for example, if someone changes the debug symbol
type in our base xcconfig files, this results in the right parameter
being set in the CFLAGS variable provided during configure. The
resulting MakeFile will then do the right thing at build time,
resulting in libraries that match our main Xcode settings.
Currently we've written a magic script that translates between common
Xcode config values and the corresponding gcc command line parameters.
The script is generic, with override values that can be set as needed
in the target of the configure build phase for a given library. This
works surprisingly well on the few open source libraries we've
experimented with so far.
But I'm concerned that we're still looking at a maintenance issue
(although greatly reduced). The problem is that this solution will
only be as good as the translation script. We can't realistically
implement every possible gcc option, so we only deal with the big
ones, like debug symbols, optimization level, SDK, symbol visibility,
etc.
Further when Apple makes changes to the dev system, we'll have to
track them. For example, if Apple moves to dwarf-3, we'll have to
change our translation script, which currently detects dwarf style
symbols and generates the command line parameter for dwarf-2.
Is there a better way for us to obtain the gcc C and Link command line
parameters for a given target? Admittedly I haven't dug into how Xcode
creates its CompileC and Ld commands. Maybe the answer is in there
somewhere.
One alternative might be a hack where we create a hello world project
that inherits from our xcconfig files, build it via xcodebuild, snag
the resulting gcc command lines, and parse out the parameters. This
could also be scripted to make it automatic. It would probably work,
but seems somewhat nasty. I'd much prefer a more direct approach to
obtaining the parameters, if possible.
Any thoughts or suggestions for a reasonable way to solve this problem
would be appreciated.
Best,
--
Allen Cronce
_______________________________________________
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