Re: Source Tree Preference
Re: Source Tree Preference
- Subject: Re: Source Tree Preference
- From: Marshall Clow <email@hidden>
- Date: Sun, 9 Nov 2003 20:21:55 -0800
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.
>
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?
>> Also, if the boost library has a ton of source and headers, you might
want to create a separate project that just deals with building the
boost libraries and then use cross-project references to refer to the
built boost library.
Thanks, but no thanks.
The boost libraries are a mix of header only template libraries
and source code files. A separately built-boost library is not possible
in many cases.
It's like a "separately built" version of the Standard Template
library.
I'm not getting this. You are telling me you can't build up a static
library for the boost pieces you use?
Yes. That is exactly what I am telling you.
Here's a piece of code. Please explain how I would build this info
a static library:
template <class T>
bool IsValid ( const T *ptr ) {
return ptr != NULL && ptr->IsValid ();
}
[ Yes, this is a made up example. If you want a real example, check
out boost's smart_ptr. ]
>> 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. ]
>
> [ 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.
--
-- 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.