Re: Source Tree Preference
Re: Source Tree Preference
- Subject: Re: Source Tree Preference
- From: Chris Page <email@hidden>
- Date: Mon, 10 Nov 2003 04:30:52 -0800
I'm not trying to jump on Scott or anybody else here, but I think this
issue deserves more voices so we're clear that Marshall isn't a
minority of one. I also think this is important to discuss not because
this particular issue can't be resolved with enough bug reports, but
because it highlights a divide in the developer community, between Mac
developers and Unix developers, that I think is worth examining.
I think the overall tone of this discussion is unnecessarily
confrontational. Recursive search paths are extremely useful and have
been used successfully by thousands of developers for decades, and it
should be a simple matter to recognize that and give thoughtful
consideration to the existence proof of their utility without trying to
convince someone they're somehow programming "wrong" if they're using
them.
On Nov 10, 2003, at 01:47, Scott Tooker wrote:
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.
I think that's overstating the case. I think it's important to note
that in about 15 years of programming this has never presented a
serious issue for me or any teams I've been on.
Now, recently I encountered this kind of problem when I began using
Boost for the first time (in conjunction with CodeWarrior), which has
some headers with the same name as the standard C libs. I had to beware
to put a separate search path for Boost in my project so it would be
searched separately and I forgot to do this when creating new projects
several times before I started to remember this requirement, which was
annoying but not a productivity killer.
On the one hand, this was unusual for me to have to do this despite
having used all kinds of libraries in many different projects over the
years, because usually those libraries were aware of--and in many cases
took advantage of--recursive search paths, and on the other hand, it's
a simple situation to recognize and resolve by arranging search paths
appropriately.
It was a simple solution that did not require that I flatten, e.g., the
MSL or PowerPlant headers into a single directory, and it did not
require that I change all my #include's to specify the parent directory
names. That's not what those intermediate directories are for, and I
need to stress this. They aren't there to enforce a file namespace on
the headers like <sys/limits.h> and <boost/limits.h>, they're there to
provide a usable arrangement of the files.
They key point here, which I'm sure a lot of non-Mac programmers may
not grok, is that Mac OS was designed to allow users to place files
anywhere they like without (to the extent possible) having to conform
to the computer's rigid ideas about where files should go or how they
should be named, and Mac developers expect this same kind of
flexibility in their development environments.
This points out that Boost and perhaps other Unix libraries are using
file naming and arrangement schemes that are quite different from those
used by Mac libraries. Given it's clear that both approaches support
capable development styles, I certainly see no need to assume that
either way is somehow "broken".
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.
The important point here is that as long as we have the ability to
define N search paths, each of which may be marked for recursive
searching or not, we developers can provide whatever organization works
best for our needs, rather than being artificially constrained to use
flat file arrangements.
Heck, take frameworks--especially umbrella frameworks--as an example.
We don't have to define search paths that point inside the includes
directory of every framework we use, and this means, for example, that
the internal arrangement of frameworks, or indeed the directory names
and locations of frameworks within umbrella frameworks, can change
without breaking client code.
Like public APIs, recursive search paths provide a separation between
clients and libraries. The internal location of files inside a
directory that represents the root of a (binary or source) library of
code is an implementation detail that clients are insulated from when
they can simply define a recursive search path that (directly or
indirectly) leads to the root folder of the library.
Like application bundles, they are not required to install headers or
binaries (or documentation, etc.) in any particular arrangement or
location like, say, "/usr/include/" and "/usr/lib/" (or, heck,
"/local/man/"). They can simply put the whole directory and all its
contents wherever they find convenient and point a recursive search
path at it. More often they simply place it anywhere below some
directory for which they've already defined a search path.
In fact, I agree that framework bundles provide a handy formalization
for grouping the various parts of a library together, but not all
libraries can or should necessarily be placed in frameworks, and
furthermore the location of frameworks themselves cannot conveniently
be abstracted by placing them within a recursively-searched hierarchy.
What it comes down to is this: Not all directories are equal. Some
serve as roots for hierarchies of folders and files whose locations
(and to a great extent, names) within that hierarchy are implementation
details that should not be relied upon by clients. Recursive search
paths recognize this important difference from directories intended to
be "flat".
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).
I haven't taken a poll, but I wouldn't be surprised if that's because
developers currently using Codewarrior are sticking with it until they
believe Xcode serves them better as a substitute, and so haven't even
taken the time to try it out or to submit bug reports. Without
recursive search paths, it is not a complete, or at least convenient,
substitute.
If getting Codewarrior developers to use Xcode is important to Apple,
this is at least one difference that can put up a significant barrier
to switching.
--
Chris Page - Software Wrangler - palmOne, Inc.
Mr. Anderson, do you hear that sound? That is the sound of
immutability. const
_______________________________________________
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.