[GRASS5] GRASS-header-file locations changed?

[Glynn Clements]

Radim Blazek wrote:

> > > Just compiled GRASS from a fresh CVS-Checkout with success. After
> > > that i tried to compile QGIS-SVN with GRASS_support.
> > >
> > > Then I realized that
> > > the include-headers are living in $GRASSINST/include/grass/*.h, but
> > > QGIS-configure searches them in $GRASSINST/include/*.h.
> > >
> > > I checked back with fromer installations of GRASS-CVS and there were
> > > $GRASSINST/include/grass/ and $GRASSINST/include/ with nearly the same
> > > content.
> > > $GRASSINST/include/grass/ has 2 more files, interpf.h and waterglobs.h.
> > > $GRASSINST/include/ only has portable.h.
> > >
> > > Is this the normal behavior or did I miss something?
> >
> > The duplicates have been removed. GRASS code (including the headers
> > themselves) now references headers as <grass/gis.h> etc.
> >
> > For external packages which haven't been updated yet, create a symlink
> > e.g.:
> >
> >         ln -s grass $GRASSINST/include/grass/grass
> >
> > then tell the configure script that the GRASS headers are in
> > $GRASSINST/include/grass rather than in $GRASSINST/include.
> 
> The external packages are using --with-grass only,
> not --with-grass-includes/libs.

That's a bug.

> 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?

The existing layout is wrong; GRASS should be able to be installed
into /usr/{bin,lib,include,share} just like every other package.

Installing headers directly into /usr/include isn't practical, due to
the number of files and the fact that some of them have very common
names (e.g. bitmap.h or colors.h).

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).

-- 
Glynn Clements <glynn at gclements.plus.com>