>> (And yes, I think X is shoddy for not following the same pathing, but
>> there's little we can do about that).
> You lost me on that one a bit... X includes can be accessed through
> /usr/include/X11 (which is symlinked over to ../X11R6/include/X11) and that
> should keep all the mappings happy. Same thing with /usr/lib/X11. I don't
> see a problem there, at least there shouldn't be. That layout predates
> the filesystem standard and, for that matter, Linux itself by quite a few
> years but still conforms reasonably well.
Well, way back when, the people who made X decided that X deserved it's own
place in /usr, thus /usr/X11 was born. Bleh.
> Hopefully, some more of the standardization efforts will pay off
> and we will see fewer customized locations for things and more apps under
> development conforming to reasonable layouts while under development.
> Moving from a development tarball to a distribution RPM (or DEB, or
> whatever)
> should require nothing more than a change of --prefix=/usr (or /) from
> --prefix=/usr/local (normal default) on the build configuration line.
> Everything from that prefix root down should remain clean. That means some
Not quite:
--sysconfdir=/etc
--localstatedir=/var
Also, I'm all for moving includes to a subdirectory of /usr/include, based on
a per project, possibly using a symlink for dev/stable selection. For example:
/usr/include/myprog-0.2
/usr/include/myprog-0.3
/usr/include/myprog -> /usr/include/myprog-0.2
That way, when you work on seperate dev/stable, you can use
#include <myprog-0.3/include.h>
to work on dev, and <myprog/include.h> when its stable, but that'd take a lot
of cooperation.
--
Ben Kosse <[EMAIL PROTECTED]>
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
