Radim Blazek wrote:
> > The external packages are using --with-grass only,
> > not --with-grass-includes/libs.
>
> That's a bug.
Why? GRASS installs everything in GISBASE.
--with-grass is path to GISBASE.
As a general rule, there's no reason to assume any kind of correlation
between library directories and header directories. The files can
always be moved from their "default" locations, and ultimately you are
going to be defining two different sets of switches in two different
variables.
FWIW, autoconf's built-in AC_PATH_X[TRA] macros produce separate
switches for X:
--x-includes=DIR X include files are in DIR
--x-libraries=DIR X library files are in DIR
even though the same "optimisation" would have worked on every X
installation I've ever seen (whether /usr/X11R<something>,
/usr/openwin or, with recent versions of X, just /usr).
> > I still believe that it is a wrong approach to make compilation of
> > other packages with GRASS support more difficult than it was before.
>
> So GRASS' is obliged to install itself according to the demands of
> third-party packages?
It breaks compilation for many people. Why we cannot
support both places untill updated GDAL/QGIS will be available?
It does not cost anything, until now there were 2 copies of header
file and it was not problem.
Mostly because I wanted to ensure that GRASS itself wasn't relying
upon multiple copies of the headers. The only practical way to do that
was to ensure that, throughout the compilation process, only one copy
was present, so that anything relying upon additional copies produced
an error.
From that perspective, much of the problem is that the mechanism for
installing two copies was spread across multiple Makefiles. The
additional copy wasn't a final step performed as part of the
installation process; headers were being installed as individual
subdirectories were being built (sometimes at the beginning, sometimes
at the end).
If it is determined that either GDAL or QGIS can't easily be updated
to handle one copy of the headers and a single symlink (e.g. through
separate --with-grass-includes and --with-grass-libs switches), and
the copy actually *needs* to be reinstated, it needs to be done as a
single step in the top-level Makefile as part of the installation
process, so that compilation (and re-compilation) isn't affected.
Actually, I can't see how the inconvenience can ever be greater than
"cp -a $GISBASE/include/grass/* $GISBASE/include". Anyone who
considers that to be a major problem should try building some other
projects from their CVS HEAD version.
> Like other sizeable packages, headers should go into their own
> subdirectory, and the subdirectory should be used in #include
> statements, as with <X11/Xlib.h>, <GL/gl.h> etc (PostgreSQL doesn't do
> this, and it's responsible for a significant proportion of
> configure-related queries to this list).
Should PostgreSQL follow demands of third-party packages?
A public interface exists solely for third-party packages. The problem
with PostgreSQL's approach is that it is generally inconvenient. OTOH,
the recent changes to GRASS are only inconvenient in that specific
packages are:
a) relying upon the previous interface (the lack of a prefix
subdirectory in the header names); whilst backwards compatibility is
important, it doesn't mean that something which is broken must stay
broken indefinitely.
b) relying upon an "accidental" feature of previous versions (the fact
that the configure script's --libdir= and --includedir= switches are
ignored, with headers and libraries always being installed into
hardcoded subdirectories of the --prefix= directory).
--
Glynn Clements <glynn@gclements.plus.com>