also libraries like netcdf/hdf might already have cmake rules somewhere?
On Sun, Feb 16, 2014 at 2:49 PM, Kyle Shannon <k...@pobox.com> wrote: > Dmitriy, > > What version of cmake is required. > > On Sat, Feb 15, 2014 at 1:31 PM, Dmitriy Baryshnikov > <bishop....@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@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > Thanks for the update. > > -- > Kyle > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
