[GRASS5] GRASS-header-file locations changed?

Glynn Clements glynn at gclements.plus.com
Tue Feb 14 14:05:25 EST 2006


Frank Warmerdam wrote:

> >>> 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.
> 
> Radim,
> 
> (forgive me if I have attribution wrong)

The first cited sentence is Radim's; the reply is mine. I'm the one
causing the problems.

> GRASS is not obligated to install itself according to the "demands"
> of third party packages.  *But* there is a high cost in disruption and
> software builder anguish to a change like moving the grass include files
> into a subdirectory.

Sure; but it was bound to happen sooner or later.

GRASS can't realistically follow normal packaging rules (e.g. 
honouring all of the built-in autoconf switches) without using a
separate subdirectory (at least four of its headers clash with files
already present in my /usr/include directory).

Additionally, the lack of a subdirectory prefix in header names risks
causing problems for third-party packages which need to include
headers from both GRASS and other packages (how do you ensure that
"#include <display.h>" includes GRASS' display.h rather than the one
from some other package?).

> It is clearly a cleaner technical solution, but I just hope you are
> aware of the implicit cost.  We will basically see several years worth
> of email from package builders about this and that external package
> not building and them not knowing why.  As an external package developer
> trying to be cooperative with GRASS, I will also get frustrated.

I appreciate that it is bound to cause problems, but it had to be done
at some point. The only issue is how to handle the transition. 

I don't mind adding (minor) "hacks" to GRASS to aid transition, but I
think that we need to provide some incentive for third party packages
to change so that the hacks can eventually be removed. I don't want a
situation where GRASS has to maintain "bug compatibility" forever so
that other packages can forever avoid updating.

IOW, there needs to be at least some trivial inconvenience to packages
which don't update. If their users have to type an explicit
--with-grass-includes= switch, that would be about right, IMHO.

> That said, does GRASS have a "grass-config" type script that other packages
> can use to determine correct libs, include and other information?  I looked
> around in my GRASS 6.0.1 install tree and didn't see anything.  While it will
> be a while before this helps, perhaps this would be a good time to introduce
> this common convention into GRASS.  Especially important would be to a
> "grass-config --libs" option as the list of libraries tends to evolve
> from release to release.

I don't think that a simple "grass-config --libs" will suffice. GRASS
has several identifiable subsystems, some of which can themselves
require substantial numbers of additional libraries.

What should "grass-config --libs" output? Just libgis and its
dependencies (which won't suffice if you need e.g. the vector
functionality), or all of the libraries?

For the latter option, look at the the dependency list for the OGSF
library if --with-ffmpeg was used:

$ ldd /opt/grass-6.1.cvs/lib/libgrass_ogsf.so
	libgrass_gis.so => /opt/grass-6.1.cvs/lib/libgrass_gis.so (0x40084000)
	libgrass_datetime.so => /opt/grass-6.1.cvs/lib/libgrass_datetime.so (0x40134000)
	libz.so.1 => /lib/libz.so.1 (0x40150000)
	libgrass_bitmap.so => /opt/grass-6.1.cvs/lib/libgrass_bitmap.so (0x40161000)
	libgrass_vect.so => /opt/grass-6.1.cvs/lib/libgrass_vect.so (0x40164000)
	libgrass_dig2.so => /opt/grass-6.1.cvs/lib/libgrass_dig2.so (0x4019b000)
	libgrass_dgl.so => /opt/grass-6.1.cvs/lib/libgrass_dgl.so (0x401af000)
	libgrass_rtree.so => /opt/grass-6.1.cvs/lib/libgrass_rtree.so (0x401c8000)
	libgrass_linkm.so => /opt/grass-6.1.cvs/lib/libgrass_linkm.so (0x401cf000)
	libgrass_dbmiclient.so => /opt/grass-6.1.cvs/lib/libgrass_dbmiclient.so (0x401d1000)
	libgrass_dbmibase.so => /opt/grass-6.1.cvs/lib/libgrass_dbmibase.so (0x401db000)
	libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0x401ea000)
	libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x404e3000)
	libGLU.so.1 => /usr/lib/libGLU.so.1 (0x4054f000)
	libtiff.so.3 => /usr/lib/libtiff.so.3 (0x405ca000)
	libavcodec.so.0 => /usr/lib/libavcodec.so.0 (0x4061a000)
	libgrass_image.so => /opt/grass-6.1.cvs/lib/libgrass_image.so (0x408e6000)
	libgrass_sites.so => /opt/grass-6.1.cvs/lib/libgrass_sites.so (0x408eb000)
	libgrass_g3d.so => /opt/grass-6.1.cvs/lib/libgrass_g3d.so (0x408f2000)
	libc.so.6 => /lib/libc.so.6 (0x40912000)
	libgif.so.4 => /usr/lib/libgif.so.4 (0x40a2a000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a32000)
	libgeotiff.so => /usr/lib/libgeotiff.so (0x40a50000)
	libpng.so.3 => /usr/lib/libpng.so.3 (0x40a71000)
	libdl.so.2 => /lib/libdl.so.2 (0x40aa1000)
	libstdc++.so.5 => /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6/libstdc++.so.5 (0x40aa6000)
	libm.so.6 => /lib/libm.so.6 (0x40b60000)
	libgcc_s.so.1 => /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6/libgcc_s.so.1 (0x40b83000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x40b8b000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x40bde000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x40be3000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x40bf2000)
	libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0x40cbb000)
	libogg.so.0 => /usr/lib/libogg.so.0 (0x40d50000)
	libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x40d55000)
	libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x40d7c000)
	libdts.so.0 => /usr/lib/libdts.so.0 (0x40e7a000)
	libfaad.so.0 => /usr/lib/libfaad.so.0 (0x40e9f000)
	libfaac.so.0 => /usr/lib/libfaac.so.0 (0x40ee2000)
	libavutil.so.0 => /usr/lib/libavutil.so.0 (0x40ef2000)
	libpostproc.so.0.0.1 => /usr/lib/libpostproc.so.0.0.1 (0x40ef6000)
	/lib/ld-linux.so.2 (0x80000000)
	libproj.so.0 => /usr/lib/libproj.so.0 (0x40efe000)
	libmp4v2.so.0 => /usr/lib/libmp4v2.so.0 (0x40f34000)

You don't want to be linking all of those in if you only need libgis.

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




More information about the grass-dev mailing list