On Thu, Oct 21, 2004 at 09:25:50AM -0400, Frank Warmerdam wrote: > Francesco P. Lovergine wrote: > >This seems a very reasonable approach. But what about headers files? > >I guess grass57 and gdal requires them each other... > > Francesco, > > Only the GDAL GRASS driver requires the grass57 include files. My proposal > is that it would be built later as a seperate package (though from the > GDAL source tree). I will go ahead and ensure the GRASS driver can be > built seperately before my GDAL 1.2.4 release. This seems to be a good starting point. Otherwise we will have to include the original gdal tarball two times into the debian archives because we have two seperate build processes of different parts of gdal. Is this right? I read a little bit more about compiling and linking dynamic libraries and I came to an idea how this could perhaps be solved: If I have library foo which is linking dynamically linking against library bar I need libbar.so at compile time of libfoo. This is not because I really want to use functions and variables of libbar.so at compile time but just to have a look whether they are defined within this library. Hence I could create a faked library libbar.so which does only provide references to the needed functions which won't work though. The sources for this faked library should be rather small and could probably be part of the gdal source code. So building grass and gdal will contain of the following steps: - build gdal with - libgdal - gdalgrassdriver (Depends: libgrass and libgdal but not Builddepends libgrass-dev since fakedlibgrass.so does provide the functionality) - libgdal-dev (Depends: libgdal) - build grass (Build-depends libgdal-dev) with: - libgrass (Depends libgdal) - grass-bin (Depends libgdal) Installing gdalgrassdriver provides now gdal with the funcionality to read grass data. Do think this is feasible? I think the main disadvantage is that we have to ensure manually that the faked libgrass in synchron with the real one. Another drawback will be if gdal uses lots of grass functions and variables. Many greetings, Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/
Attachment:
pgpa3ikqGkhMQ.pgp
Description: PGP signature