• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: SRCROOT meddling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRCROOT meddling


  • Subject: Re: SRCROOT meddling
  • From: Scott Tooker <email@hidden>
  • Date: Fri, 30 Sep 2005 19:34:36 -0700

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
References: 
 >SRCROOT meddling (From: "David Litwin" <email@hidden>)

  • Prev by Date: Re: Xcode 2.1 and .xcconfig
  • Next by Date: adding new group with applescript in XCode 2.1
  • Previous by thread: SRCROOT meddling
  • Next by thread: Re: Version Linking Issues
  • Index(es):
    • Date
    • Thread