On Jul 14, 2008, at 11:52 AM, Jeffrey Schmidt wrote:
I'm getting a new build error in Xcode 3.1. The project (a Carbon app)
previously built fine in Xcode 3.0. During any dependency check
(cleaning or building), it errors out with this:
Checking Dependencies
Argument list too long: recursive header expansion failed at
/Applications/Creator 8.0.2/MultiAd Creator
Pro.app/Contents/Resources/Help
Files/Elements/Modifying_Elements/Locking_and_unlocking_elements.
This location never figures into any header paths that a dependency
check should care about. The project and all build products live
elsewhere (or at least they used to under 3.0 and earlier), and don't
have aliases or symlinks into this location. What has changed in the
dependency checking process that causes this and how can I fix it?
I think this means you have a search path build setting which contains a recursive search path (i.e., a search path ending in "/**") which is expanding to a set of paths that are too large (the directory to expand is too large a tree). Since GCC doesn't natively support recursive search paths, Xcode simulates them by expanding such a path into a discrete -I or -F or -L flag for each directory under the parent directory, but this can rapidly expand to the point that it results in a command line too long to be issued.
The difference between Xcode 3.0 and 3.1 here is that Xcode 3.0 would silently stop expanding the recursive search path if it got too long and simply use whatever it had computed up to that point, which would result in semi-deterministic (and extremely difficult to diagnose) errors for certain types of projects. So now Xcode emits an error if it was unable to fully expand the recursive search path.
So you may need to remove that recursive search path, or modify it to expand to a smaller set of directories, or convert it to a smaller set of non-recursive search paths. Or, alternately, reorganize your source to have fewer directories the path can expand to.
Incidentally, having a smaller set of expansions could also lead to somewhat-faster compilation times, since it's fewer directories that the compiler has to search in when compiling each file. (I don't know the magnitude of impact this would have, though.)
--
Michael Rawdon
email@hidden
Xcode Developer
Apple Inc., Cupertino CA