• 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 Config files question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xcode Config files question


  • Subject: Re: Xcode Config files question
  • From: John Brisbin <email@hidden>
  • Date: Fri, 21 Nov 2008 23:03:04 -0800

Rush,

The recursive path problem arises when you have a recursive search path which may or may not directly refer to TOP_DIR. For example, it is not uncommon to have a recursive search path of  ${PROJECT_DIR}/** which represents the current (sub)project directory. Since under the scheme we are using that directory would contain a symlink to TOP_DIR, Xcode then follows the symlink to the outer containing directory represented by TOP_DIR and continues recursing through the directories of all the projects.

Because GCC does not understand recursive directory includes, Xcode traverses all those directories and includes their full paths in the command line passed to the compiler. With large projects or projects that just include many directories, their expansion into the command line can easily exceed even the generous limits of modern tools. It doesn't help the compiling performance a bit, either, even if it does not overflow the max length.

Adding TOP_DIR to the EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES prevents Xcode from following the link to the TOP_DIR and avoids the problem.

Similar command line length and compiler performance problems can occur if you 1) use a common build folder and 2) allow recursive searches of the build folder.

John Brisbin

Rush Manbert wrote:
Hi John,

I'm happy to hear that it worked for you.

We don't use recursive search paths, so I wanted to see if I understand the problem.

You have added, say, a header search path that is of the form TOP_DIR/path/in/tree/**, but since there is a TOP_DIR directory somewhere under the specfied directory, it ends up searching more places that you wanted? In fact, the entire tree under whatever TOP_DIR is linked to.

Is that it?

- Rush

On Nov 21, 2008, at 5:06 PM, John Brisbin wrote:

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.


 _______________________________________________
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: 
 >Xcode Config files question (From: Rush Manbert <email@hidden>)
 >Re: Xcode Config files question (From: John Brisbin <email@hidden>)
 >Re: Xcode Config files question (From: Rush Manbert <email@hidden>)
 >Re: Xcode Config files question (From: John Brisbin <email@hidden>)
 >Re: Xcode Config files question (From: Rush Manbert <email@hidden>)
 >Re: Xcode Config files question (From: John Brisbin <email@hidden>)

  • Prev by Date: Xcode 3.1.2 Release Notes (Chris Espinosa)
  • Next by Date: Re: Xcode 3.1.2 Release Notes (Chris Espinosa)
  • Previous by thread: Re: Xcode Config files question
  • Next by thread: compiler error/warning bubbles missing
  • Index(es):
    • Date
    • Thread