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

[Dmitriy Baryshnikov]

Hi Kyle,

The minimum version cmake is 2.8.8 because it have some required 
functionality:

add_library(<name> OBJECT <src>...) and TARGET_OBJECTS:objlib

some discussion can be found here: 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3379

But in scripts I set VERSION 2.8.10 - this is historical.

What about "pushing Find scripts back": as the work is not finished and 
GDAL and other required libraries changing, I think it's rather early to 
do. Though can be done.

Best regards,
     Dmitry

16.02.2014 21:49, 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.
>