[gdal-dev] Code sprint Korea, reformat sources tree

[Even Rouault]

Dmitry,

> 
> During the code sprint in FOSS4G 2015 (Korea, Seoul) I plan to start
> refactoring Cmake for GDAL (everybody are welcome
> http://2015.foss4g.org/programme/code-sprint/). This is good starting
> point to try release an idea to reformat source tree (combine drivers on
> some principles - raster/vector/raster+vector). I digging the mailing
> list, but didn't found discussion started by Even about this. 

Regarding unified drivers, it was a bit mentionned in 
https://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification . Basically the 
PCIDSK drivers have been merged in frmts/pcidsk, the PDF ones in frmts/pdf. 
And the raster side of GPKG has been added to the existing 
ogr/ogrsf_frmts/geopackage
Potential changes on the tree structure were left out in the "Potential 
changes that are *NOT* included in this RFC" paragraph.

> Also we have
> new type of drivers - network. So, how it'll be best to organise sources?
> This can be not only drivers, but the whole source tree. How should the
> ideal GDAL source tree looks like?
> 
> Also I plan:
> 1. Move all internal libraries (zlib, libtiff, libjpeg, etc.) to
> separate github repos to use CMake ExternalProject feature.

Just to give some context: the point for the internal libraries was to have a 
no-brainer way of building GDAL without any prerequisite.
- internal zlib is identical to its upstream v1.2.3 AFAIK
- internal libtiff: most files are identical to libtiff CVS, but a few ones 
(tiffconf.h, tif_config.h) have been modified for integration with GDAL CPL, and 
tif_vsi.c is GDAL specific (I/O implementation) + a build time hack for TIFF 
JPEG 12 bit support
- internal libjpeg is mostly upstream libjpeg v6b + one patch. There's also 
the build hack for libjpeg12

> 2. Remove any other building systems

That sounds ambitious. Given the complexity and maturity of our current build 
systems, I guess this would take some time to have CMake catch up.

> 3. Try CTest for testing

What do you think it will bring w.r.t our current testing system ? Do we want 
to be dependant of a particular build system for our tests ?
Regarding testing, I've somehow understood Kurt had mentionned plans for a 
"gdalautotest2"

Regarding all the above, I assume you mean in a fork of yours ?

> 
> As for me the ideal structure should looks like:
> + apps
> + autotests
> + bindings
> + core
>    + port
>    + ogr
>    + gcore

gnm core would go here too ?

> + cmake
> + data
> + docs
>    + doxygen
>    + readme
> + drivers
>    + raster
>    + vector
>    + network
>    + combined
> + CMakeLists.txt
> + LICENSE
> 
> So, at the root of sources tree we will have only 8 folders and 2 files.

Is the churn in the tree structure worth the effort ? Be aware that there are a 
number of interdependencies between drivers, so this might require fixing a 
number of source files. What advantages do you see in a new structure ?

I'm afraid that if you want to change multiple things at a time (build system, 
testing mechanisms, tree structure), you will never manage to get a working 
result. Incremental approaches when feasible are less risky (but admitedly 
involve potentially a larger cumulated effort).

Even

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