Re: Xcode Config files question
Re: Xcode Config files question
- Subject: Re: Xcode Config files question
- From: Rush Manbert <email@hidden>
- Date: Fri, 21 Nov 2008 16:32:10 -0800
I meant to post this last week. The symlink approach works like a
charm, and has immensely simplified our project setup. Most projects
do not need any local xcconfig files, they can just use the standard
set. (Of course there is a Debug/Release pair for apps, and a pair for
libaries, etc., but they're shared.)
We also found that we can nest the include of xcconfig files, which is
something that didn't work when I first setup the config file
structure. That also helps to make things a lot easier. (Debug/Release
pairs can both reference a common base config file)
I see that the lack of path support for xcconfig files is on the Known
Issues list for Xcode 3.1.2, so maybe they plan to fix it someday. But
if you are having trouble maintaining your config files, you might
experiment with this approach.
Best regards,
Rush
On Nov 11, 2008, at 1:34 PM, John Brisbin wrote:
The soft link scheme you describe does look promising. As you check
it out more thoroughly, please post your results.
John Brisbin
Rush Manbert wrote:
Hi John,
Yes, that's exactly the problem we have, and it has gotten to be
really annoying as we have added more projects to the mix.
We experimented yesterday with adding a symlink in the directory
where the project file lives that points to the top of the
subsystem working copy tee. Then those "../.." parts of the paths
get replaced by the link name. In your case, the includes would
become:
#include "TOP_DIR/XCConfigDocs/Generated/BuildID.xcconfig"
#include "TOP_DIR/XCConfigDocs/Generated/
CurrentInstallable.xcconfig"
and you would have a symlink named TOP_DIR in your $(SRCROOT)
directory that you made like this:
ln -s ../.. TOP_DIR
It seems to work well, and since we are using SVN we can check in
and out the links and they still work. We still need to try running
the debugger aganst an application built on this scheme, just to
make sure it doesn't get confused about where things are. If that
works (and we expect that it will), then I think we will switch
everything over to using this scheme. It drastically simplifies the
maintenance. I'm just about to go and write the Python script that
creates the links.
As an aside, we also use Boost, among a number of other third party
libraries. Currently, each of our target-level config files carries
a list of includes for other config files, one per separate third
party library. Those files define the linker command for the
library, the linker search path, and the include path. When you
make a new project, or add a target to a project, you are supposed
to copy and rename a standard template version of this config file.
That version has all of the include statements commented out. Your
job is to uncomment the lines for the libraries that you need to
use. You then base your target config on this file. This has turned
out to be a maintenance burden as well. However, since we all have
8 core Mac Pros here, we thought we would try just uncommenting all
of the include lines. In essence, this makes all of the third party
library code available to all projects, and links against all of
the third party libraries. (It seems that the newest linker makes
it so that we no longer need to worry about library link order
either, which is another reason we felt emboldened to try this.) We
were worried about what this would do to our build times, but it
made absolutely no difference. Since we dead code strip by default,
none of our linked programs changed size either. I think it's sort
of a sloppy way to go, but in our situation it seems to work very
well and again lets us vastly simplify the config file structure.
- Rush
On Nov 11, 2008, at 10:03 AM, John Brisbin wrote:
Not as far as I have discovered. Which is why each of my sub-
project xcconfig files starts something like this:
#include "../../XCConfigDocs/Generated/BuildID.xcconfig"
#include "../../XCConfigDocs/Generated/CurrentInstallable.xcconfig"
#include "../../XCConfigDocs/Global/Copyright.xcconfig"
#include "../../XCConfigDocs/Global/SigningParams.xcconfig"
#include "../../XCConfigDocs/Global/CompInstallParams.xcconfig"
TOP_DIR = ../..
... with the TOP_DIR part manually embedded into include
statements. Since not all projects are at the same level relative
to the top, this causes the expected number of errors whenever
something new is added to the list in each of the subproj xcconfig
files.
I would welcome some facility or workaround for this.
John Brisbin
Rush Manbert wrote:
I don't think this has changed in the last 2 years, but it seems
wise to ask before we go off and tear things up in our projects.
Is it possible to do something like this in a Xcode config file?
PATH_TO_TOP = "../../../../"
#include "$(PATH_TO_TOP)/common/xcconfig/
ThirdPartyLibPaths.xcconfig"
Thanks,
Rush
_______________________________________________
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:
@manbert.com
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
_______________________________________________
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