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

[Etienne Tourigny]

also libraries like netcdf/hdf might already have cmake rules somewhere?



On Sun, Feb 16, 2014 at 2:49 PM, Kyle Shannon <kyle at pobox.com> wrote:

> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140216/112c8492/attachment-0001.html>