• 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: Xcode keeps mucking up search paths
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xcode keeps mucking up search paths


  • Subject: Re: Xcode keeps mucking up search paths
  • From: Fritz Anderson <email@hidden>
  • Date: Wed, 18 Dec 2013 12:58:19 -0600

On 17 Dec 2013, at 6:57 PM, Rick Mann <email@hidden> wrote:

> I just re-added a framework to my project. It was already in the Files & Groups list, I just checked the target membership for the target in the right-hand File Inspector pane.
>
> Xcode unhelpfully added an absolute search path to that framework (even though it's beneath the project folder), and added a bunch of backslashes into a different search path, rendering it unusable.
>
> I've reported the first bug already.

I offer this with the caveat that I'm not sure the Project-navigator path has any influence over the build-time framework search path…

Select the File inspector in the Utility (right-side) area, then select the framework. (I assume this is a framework of your own, or third-party?) What do the location popup and the relative path below it say? If it's either absolute or has a lot of /../ directories, that's not what you want (usually). You want the location popup to say it's "relative to" something. Select the option that looks best; you may have to click the folder icon next to the path to re-orient Xcode to the location.

If "Relative to Group," go up the group hierarchy and ensure that each group has a relative path that suits your purpose.

Something in, or sharing an ancestor with, a relative anchor will get you /../s or absolute paths. The latter are undesirable, and I've found the former fragile. (People who keep project components outside of project directories often do so to satisfy their private file organization habits.)

If trees not relative to the project (etc.) aren't avoidable, set up a source tree (Preferences window, Locations panel) to give the root of the external tree a symbolic name that each user can assign a path to. Then make the problem resource relative to the source tree. Each developer will have to set up her own definition of the tree, but the project remains portable and well-ordered.

That, at least, is how we silence target and navigation errors for paths that depend on one developer's directory organization. You'd think that would surely have some influence on search paths, but there are lots of things that are "surely" true, but aren't.

And sometimes even that doesn't cure red-file problems.

	— F


--
Fritz Anderson	     email@hidden
Xcode 5 Start to Finish: Available April 2014 from Addison Wesley


 _______________________________________________
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


  • Prev by Date: Crash: "Can't get the OID of an object not in the document!"
  • Next by Date: Re: Problems crashing when NOT exporting some C++ symbols
  • Previous by thread: Crash: "Can't get the OID of an object not in the document!"
  • Next by thread: Re: Problems crashing when NOT exporting some C++ symbols
  • Index(es):
    • Date
    • Thread