RE: SRCROOT meddling
RE: SRCROOT meddling
- Subject: RE: SRCROOT meddling
- From: "David Litwin" <email@hidden>
- Date: Mon, 3 Oct 2005 11:28:37 -0700
Thanks for clarifying that SRCROOT out of bounds.
I considered a source tree, but I want someone to be able to grab this from
source control and build. Since, I presume, the source tree settings are
stored in the user specific com.apple.Xcode.plist (with absolute paths), I
can't put them in source control.
What I came up with was to add my own variable (BES, in my case) relative to
SRCROOT in the shared project config file. I can then use this in all the
places where I would have found it useful to use SRCROOT (SYMROOT, OBJROOT
as well as header paths and library include paths) use BES as the source
root, but avoid messing up SRCROOT:
Proj.xcconfig:
BES=$(SRCROOT)/../../..
SYMROOT=$(BES)/../Builds
OBJROOT=$(BES)/../IntermediateFiles
LIBRARY_SEARCH_PATHS=$(BES)/../Libraries/$(CONFIGURATION)
Dave
-----Original Message-----
From: Scott Tooker
We really need to make the documentation language stronger. It is NOT
recommended to change SRCROOT, it is meant to be a read-only setting.
If you really want a build setting that points to a directory
external to a project, use a source tree.
Scott
On Sep 28, 2005, at 6:41 PM, David Litwin wrote:
> Thanks, this worked to solve the build locations issue.
>
> The next problem I'm having is with SRCROOT. Since our code for many
> projects is all under one source root separate from any project, it
> seemed
> ideal to set the SRCROOT to our top level directory. The docs
> don't really
> say you shouldn't, just that "you should not have to modify this build
> setting". For most projects I would probably agree, but in my case
> it seems
> useful.
>
> The problems arise when I add external libraries to the project
> from these
> locations, and use the relative to Project" path type. It seems
> when you
> use this type it is calculated as relative to the SRCROOT, but then
> emitted
> to the compiler relative to the project dir, causing the file not
> to be
> found.
>
> I work around this by making the files relative to their Enclosing
> Group,
> but that isn't the default when you add a file and so I've had to
> track down
> a number that I've missed.
>
> I'm guessing this is just a bug where the code that saves the path
> "Relative
> to Project" is assuming SRCROOT is the project path.
>
> Dave
>
> P.S. This isn't a problem with the static libraries because I just
> let
> XCode find them where the other projects build them by adding them
> from the
> sub project disclosures. But these are dynamic libs and that
> doesn't work
> (a question I posted to the list a few days ago that has yet to be
> addressed...) so I have to manually add one (in my case I chose
> Release) to
> the External Frameworks and Libraries section.
>
>
> -----Original Message-----
> From: xcode-users-bounces+david_litwin=email@hidden
>
> On Sep 27, 2005, at 7:23 PM, David Litwin wrote:
>> I'm working on an app built from a set of static and dynamic library
>> projects. Each is its own project, and all have custom build
>> locations so
>> they can be found by the other projects that depend upon them. I
>> got all
>> the interdependencies working fine, and all was well.
>
> If you want everyone to use the same build locations, you can set
> these in the project build settings (search for SYMROOT and OBJROOT).
> However, the per-user per-project settings will still override the
> project settings in this case.
>
> Scott
>
>
> _______________________________________________
> 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