Re: Xcode Config files question
Re: Xcode Config files question
- Subject: Re: Xcode Config files question
- From: Rush Manbert <email@hidden>
- Date: Tue, 11 Nov 2008 10:36:44 -0800
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:
@nakasuji.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