RE: Source Tree Preference
RE: Source Tree Preference
- Subject: RE: Source Tree Preference
- From: Andy Satori <email@hidden>
- Date: Mon, 10 Nov 2003 10:44:32 -0500
I wish Mail.app didn't lose the account when you filter things to a
folder :-(.
Andy
Begin forwarded message:
> From: Andy Satori <email@hidden>
> Date: November 10, 2003 10:10:18 AM EST
> To: Scott Tooker <email@hidden>
> Cc: Marshall Clow <email@hidden>, email@hidden
> Subject: Re: Source Tree Preference
>
> Let me provide a real world solution where this is a problem, and how
> it's dealt with in another world.
>
> Visual Studio.NET 2003 C++. Build and try to compile an application
> that implements the IBandObject interface, using the Microsoft Example
> code if you wish.
>
> Click Compile. (it won't in the default configuration).
>
> Do a Find In Files of the IBandObject Interface ID. You'll find it
> buried deep in the hierarchy, in the correct file name, but the wrong
> path.
>
> The problem is that the search path pulls the file that i hits first
> in the search path, the default installation puts the correct
> ShellObj.h file about 4 down the list and therefore example code
> doesn't work.
>
> If this wasn't recursive, you wouldn't see the alternate header at
> all. So instead of having a missing declaration altogether, you have
> a mismatched version.
>
> In the case of Windows, this exact situation is brought about by the
> way they support multiple versions of the same API with #defines and
> different directory structures.
>
> The XCode approach is, in my opinion, the right one. It also has the
> added benefit of reducing the risk to the developer of accidently
> including cross version dependancies in the platform SDK's.
>
> By the way, spouting about how CodeWarrior does things isn't
> necessarily a good thing. I spent many years working with Watcom's
> C++ on OS/2 and Windows. I swear that both the CodeWarrior and Watcom
> UI's are classic examples of how NOT to write an IDE. Perpetuating
> that toture upon anyone in a modern development environment is "Cruel
> and Unusual Punishment".
>
> Andy
>
>
> On Nov 10, 2003, at 4:47 AM, 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.
>>
>> 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.
[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.