<div dir="ltr">also libraries like netcdf/hdf might already have cmake rules somewhere?<div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 16, 2014 at 2:49 PM, Kyle Shannon <span dir="ltr"><<a href="mailto:kyle@pobox.com" target="_blank">kyle@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dmitriy,<br>
<br>
What version of cmake is required.<br>
<div class=""><br>
On Sat, Feb 15, 2014 at 1:31 PM, Dmitriy Baryshnikov<br>
<<a href="mailto:bishop.dev@gmail.com">bishop.dev@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> As cmake4gdal developer I think there is no problem with cmake. By now we<br>
> main code is cmaked, and deal only with some drivers (GDAL or OGR), which<br>
> needed cmake scripts.<br>
> I make needed cmake scripts for drivers what I use in may work.<br>
<br>
</div>Are any of your Find* scripts being pushed back into the cmake code<br>
base, or do they live exclusively in the GDAL source tree?  It's<br>
strange to me that cmake doesn't come bundled with find scripts for<br>
libs like sqlite and mysql, they are fairly common.<br>
<div><div class="h5"><br>
><br>
> So, with some help we can do all cmake scripts rather fast.<br>
><br>
> The current implementation is here:<br>
> <a href="https://github.com/nextgis/gdal-svn/tree/cmake4gdal" target="_blank">https://github.com/nextgis/gdal-svn/tree/cmake4gdal</a> and<br>
> <a href="https://github.com/aashish24/gdal-svn/tree/cmake4gdal" target="_blank">https://github.com/aashish24/gdal-svn/tree/cmake4gdal</a><br>
> The branches include not the latest GDAL repository commits, as they can<br>
> include makefile chages, so there is some delay as I synchronize the<br>
> branches.<br>
><br>
> Now there are scripts to:<br>
> 1) all libraries - CPL, GDAL, OGR<br>
> 2) apps - gdaladdo, gdalbuildvrt, gdalinfo, gdallocationinfo, gdalwarp,<br>
> gdal_contour, gdal_grid, gdal_translate, ogr2ogr, ogrinfo, test_ogrsf<br>
> 3) GDAL drivers - bmp, dimap, gif, tiff, hfa, iso8211, jpeg, map, mem, ozi,<br>
> png, postgisraster, raw, saga, til, vrt, wms<br>
> 4) OGR drivers - csv, dxf, generic, geojson, gml, gpx, kml, libkml, mem,<br>
> mitab, mysql, pg, s57, shape, sqlite, sxf, vrt, wfs<br>
><br>
> Best regards,<br>
>     Dmitry<br>
><br>
> 15.02.2014 22:57, Even Rouault пишет:<br>
><br>
>> Thanks for your thoughs Kyle. I expect more developers and PSC members to<br>
>> express theirs too.<br>
>><br>
>>> How long would the stable branches be maintained?  Would we handle as<br>
>>> we do now, with one stable branch and one development branch, or would<br>
>>> we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this<br>
>>> require maintaining 3 branches?  stable, trunk, and api_break?  Any<br>
>>> thoughts?<br>
>><br>
>> What would be the api_break branch, as opposed to trunk I mean ?<br>
>> Maintaining 2 branches in addition to the development branch seems to be a<br>
>> bit<br>
>> too much work. Well, backporting is not that difficult generally, but<br>
>> releasing<br>
>> a version is an effort that takes some energy and time, so we would have<br>
>> likely<br>
>> difficulty in making the necessary releases. But anyone wanting to<br>
>> maintain a<br>
>> branch can do it, so there's no need to set that policy in stone.<br>
>><br>
>>>> An alternative would be to prepare the API for new features even if they<br>
>>>> are not implemented, but that's a difficult exercise and there's a risk<br>
>>>> that at implementation time, the API doesn't fit.<br>
>>>> Any thoughts ?<br>
>>>><br>
>>>> Currently we have no such breakage in trunk so it could qualify as GDAL<br>
>>>> 1.11. Perhaps we should just release it as such for now before the<br>
>>>> bigger changes ?<br>
>>><br>
>>> Maybe release 1.11 soon, and take a crack at 2.0 changes before the<br>
>>> next release?  This would probably require a concerted effort from<br>
>>> developers or funders, as Even mentioned in regard to the sprint.<br>
>>><br>
>>>> Somes topics I can see for GDAL 2.0 that impact API/ABI :<br>
>>>> - well, the mythological unification of OGR driver model with GDAL<br>
>>>> driver<br>
>>>> model.<br>
>>>> - XYZM support<br>
>>>> - Curve geometries<br>
>>>> - 64 bit integer support<br>
>>><br>
>>> The 64-bit integer changes seem fairly straight forward.  I see XYZM<br>
>>> support up for GSoC again, maybe it'll get picked up.  I have no idea<br>
>>> what curve support would entail.<br>
>><br>
>> Well, new geometry types and enhancements in drivers that would support<br>
>> them<br>
>> (PostGIS, ...). And also likely adapt all existing drivers that have write<br>
>> support so they can deal with the new geometry types : ignore them, or<br>
>> take<br>
>> them into account.<br>
>><br>
>>>> Other possible structural changes :<br>
>>>> - Change of master version control system: switch to git / GitHub ?<br>
>>>> - New build system : cmake ?<br>
>>><br>
>>> What are the benefits here?  > Is travis integration easier?<br>
>><br>
>> Well, I put that on the table since it is sometimes mentionned by<br>
>> developers,<br>
>> but the effort vs benefit ratio is not completely obvious for existing<br>
>> GDAL svn<br>
>> commiters.<br>
>> git transition would be mainly to keep up with what developers are of will<br>
>> soon be familiar with. Someone pointed me recently that GitHub also<br>
>> exposed<br>
>> git repositories as subversion repositories (which I experimented a bit),<br>
>> so<br>
>> that could satisfy most developers. git has the benefit of easing porting<br>
>> patches between branches, and making contributions from casual developers<br>
>> easier. Since the git mirror already exists, the transition to github<br>
>> would<br>
>> essentially require porting the Trac database to Github tickets (we could<br>
>> benefit from MapServer experience that has done that move before)<br>
>><br>
>>> I believe<br>
>>> someone has a cmake port floating around on github, any comments<br>
>>> there?<br>
>><br>
>> The effort seems to have stalled. The benefit here would be the<br>
>> unification of<br>
>> the Unix and Windows makefiles, but the complexity of GDAL dependencies<br>
>> makes<br>
>> the porting effort rather repelling...<br>
>><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
</div></div>Thanks for the update.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Kyle<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></div></blockquote></div><br></div></div>