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

[Kyle Shannon]

Dmitriy,

What version of cmake is required.

On Sat, Feb 15, 2014 at 1:31 PM, Dmitriy Baryshnikov
<bishop.dev at gmail.com> wrote:
> 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.

Are any of your Find* scripts being pushed back into the cmake code
base, or do they live exclusively in the GDAL source tree?  It's
strange to me that cmake doesn't come bundled with find scripts for
libs like sqlite and mysql, they are fairly common.

>
> 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...
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

Thanks for the update.

-- 
Kyle