On 2009-08-01 19:40:25 -0700, David Schwartz wrote:
> The root problem is that /usr/local/include is used both for local
> installation customizations that are intended to always change the
> normal distribution behavior and for locally installed additions
> that are not intended to affect normal system behavior. Those two
> uses call for different search path behavior.
>
> The ideal solution would be to bifurcate /usr/local (or at least
> /usr/local/include and /usr/local/lib) into one path for
> customizations intended to modify default behavior and one for
> additions meant to be used when specifically asked for.
This is not that simple. IMHO, the main problem is that /usr/local is
used as the default $prefix for most software, so that users install
software there without knowing the consequences, in particular when
they install libraries that have a different API from those provided
by the vendor. Moreover this conflicts with systems of ports. For
instance, under Mac OS X, MacPorts knows about these problems, but
there's no clean way to say: let's only depend on /usr/{include,lib}
(where the vendor's libraries are) and /opt/local/{include,lib} (the
libraries installed by MacPorts), ignoring /usr/local (or having it
at a lower precedence). According to POSIX, -I and -L should be able
to do that, but this is incompatible with GCC's use of -I (due to its
notion of system headers and the fact that /usr/local/include is seen
as a system header path).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
|