> I have no idea what could be submitted and what couldn't. > So, if you care, submit a pull request > https://github.com/json-c/json-c > or just forward these functions to > https://groups.google.com/forum/#!forum/json-c
I'll try to, but not before end of week. > I have patched json-c for Windows and Visual C++, and patches have > been accepted, > so I guess there is no problem with building for Windows/OSGeo4W. Do we need json-c 0.10 to be able to build it for Windows ? Or was 0.9 already OK ? > > >> I don't see any reason why GDAL couldn't rely on external json-c. > >> So, I'd like to propose to: > >> - remove GDAL's copy of json-c from ogr/ogrsf_frmts/geojson/jsonc > >> - configure Unix and Windows builds to use external binaries > > > > I assume you will deal with the libjsonc dependency as an optional one ? > > If GDAL agrees to use external libjsonc, then I will make it optional > in build config. > If that's what you mean. Yes > > For the ease of using on Linux, it would be good if libjson-c 0.9 could > still be > > used, being the version currently packaged. > > I have no idea to what extent the API has changed in 0.10, but I can > give it a try. Hopefully the API (at least, the subset used by the GDAL/OGR drivers) hasn't changed. If it has, I think we will have to adapt to the 0.9 and 0.10 API. > To summary, I plan the following steps during next week or so: > > 0. Work will happen in trunk only > 1. I will remove the json-c sources > 2. I will configure build to use external libjsonc (preferably 0.9+) > 3. I will update the drivers, if necessary. > 4. I will update the tests, if necessary. > 5. Once confirmed sound on Linux, I will push changes as single commit. > 6. I continue testing on Windows (hopefully someone will be willing to > help with testing for Windows). > > Do you agree? > > I think I'll make a ticket for reference too. Sounds good to me. If we need libjson-c 0.10 for having something that builds under Windows, then I think it will be best to wait for it to be officially released before removing the internal copy from GDAL trunk. Best regards, Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
