Re: Source Tree Preference
Re: Source Tree Preference
- Subject: Re: Source Tree Preference
- From: Scott Tooker <email@hidden>
- Date: Mon, 10 Nov 2003 01:47:58 -0800
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.
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).
>> >
>>>> 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.
>> >> 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).
>
>
>> >
>> > [ 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).
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.
Scott
> --
> -- 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.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.