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