[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Dmitriy Baryshnikov]

Hi,

As cmake4gdal developer I think there is no problem with cmake. By now 
we main code is cmaked, and deal only with some drivers (GDAL or OGR), 
which needed cmake scripts.
I make needed cmake scripts for drivers what I use in may work.

So, with some help we can do all cmake scripts rather fast.

The current implementation is here: 
https://github.com/nextgis/gdal-svn/tree/cmake4gdal and 
https://github.com/aashish24/gdal-svn/tree/cmake4gdal
The branches include not the latest GDAL repository commits, as they can 
include makefile chages, so there is some delay as I synchronize the 
branches.

Now there are scripts to:
1) all libraries - CPL, GDAL, OGR
2) apps - gdaladdo, gdalbuildvrt, gdalinfo, gdallocationinfo, gdalwarp, 
gdal_contour, gdal_grid, gdal_translate, ogr2ogr, ogrinfo, test_ogrsf
3) GDAL drivers - bmp, dimap, gif, tiff, hfa, iso8211, jpeg, map, mem, 
ozi, png, postgisraster, raw, saga, til, vrt, wms
4) OGR drivers - csv, dxf, generic, geojson, gml, gpx, kml, libkml, mem, 
mitab, mysql, pg, s57, shape, sqlite, sxf, vrt, wfs

Best regards,
     Dmitry

15.02.2014 22:57, Even Rouault пишет:
> Thanks for your thoughs Kyle. I expect more developers and PSC members to
> express theirs too.
>
>> How long would the stable branches be maintained?  Would we handle as
>> we do now, with one stable branch and one development branch, or would
>> we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this
>> require maintaining 3 branches?  stable, trunk, and api_break?  Any
>> thoughts?
> What would be the api_break branch, as opposed to trunk I mean ?
> Maintaining 2 branches in addition to the development branch seems to be a bit
> too much work. Well, backporting is not that difficult generally, but releasing
> a version is an effort that takes some energy and time, so we would have likely
> difficulty in making the necessary releases. But anyone wanting to maintain a
> branch can do it, so there's no need to set that policy in stone.
>
>>> An alternative would be to prepare the API for new features even if they
>>> are not implemented, but that's a difficult exercise and there's a risk
>>> that at implementation time, the API doesn't fit.
>>> Any thoughts ?
>>>
>>> Currently we have no such breakage in trunk so it could qualify as GDAL
>>> 1.11. Perhaps we should just release it as such for now before the
>>> bigger changes ?
>> Maybe release 1.11 soon, and take a crack at 2.0 changes before the
>> next release?  This would probably require a concerted effort from
>> developers or funders, as Even mentioned in regard to the sprint.
>>
>>> Somes topics I can see for GDAL 2.0 that impact API/ABI :
>>> - well, the mythological unification of OGR driver model with GDAL driver
>>> model.
>>> - XYZM support
>>> - Curve geometries
>>> - 64 bit integer support
>> The 64-bit integer changes seem fairly straight forward.  I see XYZM
>> support up for GSoC again, maybe it'll get picked up.  I have no idea
>> what curve support would entail.
> Well, new geometry types and enhancements in drivers that would support them
> (PostGIS, ...). And also likely adapt all existing drivers that have write
> support so they can deal with the new geometry types : ignore them, or take
> them into account.
>
>>> Other possible structural changes :
>>> - Change of master version control system: switch to git / GitHub ?
>>> - New build system : cmake ?
>> What are the benefits here?  > Is travis integration easier?
> Well, I put that on the table since it is sometimes mentionned by developers,
> but the effort vs benefit ratio is not completely obvious for existing GDAL svn
> commiters.
> git transition would be mainly to keep up with what developers are of will
> soon be familiar with. Someone pointed me recently that GitHub also exposed
> git repositories as subversion repositories (which I experimented a bit), so
> that could satisfy most developers. git has the benefit of easing porting
> patches between branches, and making contributions from casual developers
> easier. Since the git mirror already exists, the transition to github would
> essentially require porting the Trac database to Github tickets (we could
> benefit from MapServer experience that has done that move before)
>
>> I believe
>> someone has a cmake port floating around on github, any comments
>> there?
> The effort seems to have stalled. The benefit here would be the unification of
> the Unix and Windows makefiles, but the complexity of GDAL dependencies makes
> the porting effort rather repelling...
>