[FGS] Source Cache, CVS access

Frank Warmerdam warmerdam at pobox.com
Tue Jul 3 17:19:48 EDT 2007

Daniel Morissette wrote:
> You could look at the way "modules" are built for the PHP package. 
> Actually, I see two approaches being used, there are modules inside the 
> pkg_def/php directory for curl, pdf, mysql, etc. and there are 
> individual packages under pkg_def/php_* for php_ogr, php_sqlite, etc. I 
> guess the former are for modules whose source comes as part of the PHP 
> source tree and the latter are for packages whose source comes from a 
> different source, but I could be wrong.
> Anyway, I just wanted to mention that some packages already have 
> sub-modules (mapserver-php is another example) and you should look at 
> how they work to develop your GDAL plugins.


I looked at the php modules a bit.

I did my prototype gdal_ecw module for the ECW plugin driver
according to the prototype of python_mapscript which has it's
own directory in pkg_def, and is explicitly listed in the build.list
file.  I see that mechanism and the approach used in the php case both
end up producing fgs-*-module*.tar.gz files so the final result
seems to be the same.  Do you see any compelling reason to do
things one way or the other?

I see the gdal_ecw and python_mapscript modules are specified in
the build.list file with the version number referrning to their
parent package (where their source lives).

Currently GDAL doesn't really support producing plugins in a
convenient way, unlike PHP, so doing them as seperate packages
at least keeps the hackery distinct from the base gdal build.

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

More information about the Foss-gis-suite mailing list