Rush,
In the mean time, I converted my projects to use your technique.
It worked well ... and better when I added the "TOP_DIR" to those
excluded from recursive search with the line:
EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES = TOP_DIR
*.nib *.lproj *.framework *.gch (*) CVS .svn *.xcodeproj *.xcode
*.pbproj *.pbxproj
in a globally included xcconfig file.
Without it, the dreaded 'command line too long' sorts of errors crept
into compiles wherever the search path included a TOP_DIR symlink.
Thanks for the idea,
John Brisbin
Rush Manbert wrote:
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:
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
|