Re: Source Tree Preference
Re: Source Tree Preference
- Subject: Re: Source Tree Preference
- From: Marshall Clow <email@hidden>
- Date: Mon, 10 Nov 2003 07:33:14 -0800
At 1:47 AM -0800 11/10/03, Scott Tooker wrote:
On Nov 9, 2003, at 8:21 PM, Marshall Clow wrote:
At 3:59 PM -0800 11/9/03, Scott Tooker wrote:
On Nov 9, 2003, at 10:03 AM, Marshall Clow wrote:
Scott Tooker <email@hidden> wrote:
Just to clarify some things:
1. Xcode doesn't support recursive search paths.
A major failing, IMNSHO.
What's the rationale here?
We looked at doing this, but it doesn't pay on Mac OS X where there is
a much higher rate of multiple files with the exact same name. Too
often, the recursive case would bite you hard by picking up the wrong
version.
So to prevent possible future errors, you chose to punish the developers
that you are trying to attract. Not the best way to win friends, IMHO.
I'll just point out that multiple files with the same name has
always been problematic. Recursive search paths just makes the
failures more subtle and/or difficult to understand. Such failures
were unlikely on Mac OS 9, where the chance of having two
identically named files was small. However, on X, it is much more
likely to occur.
I just looked at my MacOS 9 machine.
It has 4 files named "limits.h" on it, and I have never had any
trouble keeping them straight,
and the tools I use there have _never_ included the wrong one.
If you really want such a feature, file a bug. If we get a bunch of
feedback that developers want recursive search paths, we'll look at
the issue again. However, I have seen very few requests for the
feature recently (yours is the first I remember in several months,
if not the better part of a year).
Convenient, that.
Since XCode has only been available to developers for less than 5 months.
I will file a bug, but I fully expect it to be "Closed, works as designed".
2. The 'Source Trees' support provides a way for users to define
custom
root paths. For example, the CodeWarrior Importer defines a source
tree
that points to the "Metrowerks CodeWarrior" folder on your disk. This
makes it possible to define a relative path to PowerPlant files that
works for multiple users. Of course, this requires that each user
define the same Source Tree name in their preferences.
But amazingly unhelpful, given #1 above.
It assumes that all the code that I share between projects
lives in a single directory. PowerPlant, boost, Whisper, crypto++, etc,
none of these follow that model.
This makes porting my CW projects to XCode a major PITA.
All that the 'Source Trees' feature provides is a way to define a path
root that is per-user.
So you agree that it's useless for what I'm trying to do?
It solves a different problem, namely it provides a way for multiple
users to share a project where part (or all) of the sources exist at
a known root that varies for each person (many times the only
variance is different volumes names). Any project that uses
PowerPlant files and is shared among multiple users will run into
this.
The fact that Xcode/gcc doesn't support recursive search paths is an
independent issue.
Then why did you suggest it as a solution to the problem of the lack
of recursive search paths
in the first place?
>> At this point you'll probably need to add header search paths as needed
>> (though, since you've included all the headers you shouldn't need many).
>
> There's only about 40 of them - that shouldn't take too long.
> That's a lot of work, to make up for a failing in XCode (see #1 above).
>
> I've been using XCode for a couple of weeks, and except for the bugs,
> this is the thing that's giving me the most problems - finding files.
Like I've stated before, Xcode works better when you are explicit about
which header files you are including. Usually this explicitness is
achieved by adding the actual header files to the project.
Ok, if I add two headers named "Resources.h" to my project, and write:
#include "Resources.h"
which one will be included?
[ No, this is not a made up example. ]
As far as I can recall, I believe that we will prefer a header file
that is in the same directory as the including file will be found
first (then we fall back to what is in the project, and failing that
we look at the search paths).
More obscure, unchangeable rules.
How many sets of undocumented rules for searching for files are there
in this system?
And how can I get a summary of this out of my project?
In CodeWarrior, this is easy - open the "Access Paths" preference
panel, and all the places
that the IDE will search are listed for you - just as you entered them.
> [ Bug: When I select a file name and hit "cmd-shift-D", it should
> NEVER EVER
> open a file that is different from the one that the compiler will use.
> ]
Did you file it?
I reported it directly to Chris Espinosa.
Well, for this issue there are a number of related bugs filed. The
good news is that 'Open Quickly' should be more SDK-savvy and be
able to find files that are in the project (support for looking
automatically in included frameworks isn't there yet).
No, it shouldn't be more SDK-savvy. It should use the same code as
all the other tools use
to locate files. In fact, there should be one copy of that code in
the entire system, and all
the tools should use it - then they would all open files identically.
Unfortunately, it doesn't appear that any bug was filed on what you
are specifically talking about (i.e. if a project uses gcc 3.1 then
we should use the 3.1 headers, not the 3.3 headers).
Please file a bug, since this is the one way to ensure we track the
issue. This also ensures that two-way communication on the issue is
possible.
Are you suggesting that talking to Chris is not "two way communication"?
However, I have filed a bug. rdar://3478616
--
-- Marshall
Marshall Clow Idio Software <mailto:email@hidden>
Hey! Who messed with my anti-paranoia shot?
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.