No subject


Wed Nov 14 13:37:45 EST 2007


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 at gclements.plus.com>




More information about the grass-dev mailing list