+1 from a non-voting person. It will definitely make testing a lot cleaner / easier without having to run a separate binary to get most of the testing done. There is also an enormous amount of python code that runs os.system / subprocess. That code is very error prone / a pain to maintain.
General thoughts / questions: (I only skimmed, so apologies for dumb comments) - Will this stuff be thread safe? - Is it possible to have an optional ptr to an error return? This would make thread safety easier. Or is that *bUsageError? - If the argument parsing to options data structure was also a part of the library, we could test the arg parsing in C++ without having to shell out to a program. - Can we get away from 0/FALSE and TRUE/1 for bools in in C++. e.g. psOptions->bQuiet -kurt On Wed, Aug 26, 2015 at 12:56 PM, Kyle Shannon <k...@pobox.com> wrote: > On Wed, Aug 26, 2015 at 1:55 PM, Even Rouault > <even.roua...@spatialys.com> wrote: > > Le mercredi 26 août 2015 21:44:10, Kyle Shannon a écrit : > >> Hi, > >> > >> On Wed, Aug 26, 2015 at 12:27 PM, Even Rouault > >> > >> <even.roua...@spatialys.com> wrote: > >> > Hi, > >> > > >> > Summer of code 2015 being finished now, Faza's work now include > >> > librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. > Faza > >> > will continue working on some other utilities. > >> > >> Which other utilities are being considered? Has there been any > >> discussion or thoughts on this? > > > > I think we discussed with Faza about pursuing with gdalbuildvrt. gdaldem > would > > probably be interesting too. Anyone interested can contribute to the > effort. > > > >> > >> > We'd be happy to hear about your comments, especially on the API. So > >> > speak now please. > >> > >> The API looks good to me. > >> > >> How does documentation work for utilities now? > > > > You mean for the binaries ? Well, it is unchanged. Mainly in > > gdal_utilities.dox, and for some of them (gdalwarp at least), in the > .cpp. > > > >> I guess changes should > >> be documented in the *_lib.cpp or *_lib.h and also gdal_utilities.dox, > >> similar to how the utilities closely coupled with certain alg/ APIs > >> (gdalgrid for example). > >> > >> > The overview of the work is there: > >> > https://trac.osgeo.org/gdal/wiki/rfc59_utilities_as_a_library > >> > >> If I am reading correctly, a separate lib will now be created. Is > >> this to keep the building cleaner? Is there a problem with just adding > >> it to the libgdal C API? > > > > The idea was to be a bit more modular, and avoid growing the core > library. > > > >> > >> > I'd like to call for a vote soon as I'd want that to be merged as > soon as > >> > possible, so it gets more widely tested and to avoid increasing merge > >> > difficulties. > >> > > >> > Even > >> > > >> > -- > >> > Spatialys - Geospatial professional services > >> > http://www.spatialys.com > >> > _______________________________________________ > >> > gdal-dev mailing list > >> > gdal-dev@lists.osgeo.org > >> > http://lists.osgeo.org/mailman/listinfo/gdal-dev > >> > >> Thanks. > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > Thanks Even... > > -- > Kyle > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev