[gdal-dev] GDAL packaging in OSGeo4W

Even Rouault even.rouault at spatialys.com
Mon Feb 22 06:04:14 PST 2016


Le lundi 22 février 2016 14:38:06, Jürgen E. Fischer a écrit :
> Hi Even,
> 
> On Mon, 22. Feb 2016 at 12:15:31 +0100, Even Rouault wrote:
> > Following recent exchanges on the discuss mailing list, it appears that
> > the whole set of packages in OSGeo4W relies on very few shoulders. I was
> > wondering if someone would be willing to take the stick for GDAL.
> > 
> > Could be cool to have -dev versions packaged from time to time (or
> > potentially nightly builds), as well as a few drivers available as
> > plugins (PDF driver, MongoDB one)
> 
> PDF is included (but not as plugin).

Ah honestly I didn't try recently. Just looked at 
http://download.osgeo.org/osgeo4w/x86_64/release/gdal/setup.hint . If the 
build dependencies are just those ones, then it must be only the write support 
of the PDF driver which requires no dependency. For read-support, you need  
poppler for raster&vector read support, or podofo for vector read support only 
(or pdfium - new to trunk - for raster&vector read support, PDFium being 
licensed under non-copyleft terms).

> mongo db however is missing, yes.

Yes, trunk only anyway

> 
> Well, and the discussion might be a bit misled.  My point was that OSGeo4W
> is not stalled - eventhough I'm not keen on building all the stuff with an
> (even bigger) zoo of compilers.

Sure, building the whole stack with different compilers would require an 
automated process, and as automation doesn't work alone, people behind it.

> Because I don't really see a point in
> that - for me OSGeo4W is about shipping applications and not development
> libraries.

Perhaps you meant "shipping development libraries.... for a number of compiler 
version, with/without debug symbol, etc..." ? Because at least the .h and .lib 
corresponding to the used compiler must be provided, so as to be able to build 
upper level packages.

> 
> Doing a build once in a while (and maybe even adding a nightly - I run the
> qgis nightlies anyway) shouldn't be a big problem.   But this came only up
> once in a while - IIRC more like a nice idea, but not like real request. 

My email was more about to try to find if the load can be shared. It shouldn't 
fall on QGIS to build the whole stack since most packages have their 
usefulness individually.

> Maybe also because it would be of limited use, if "upper level" package
> like QGIS would not use the gdal nightly.
> 
> But would probably not be what you intended ;)

That may be a chicken&egg problem. If there are no GDAL dev builds, nobody is 
going to try them.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list