Hi Kurt, > +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?
It should. Normally all static stuff from program code is supposed to have been removed > - Is it possible to have an optional ptr to an error return? This would > make thread safety easier. Or is that *bUsageError? The functions will emit CPLError(). *bUsageError is a flag mainly to be used by the command line utilities to display the usage message in case conflicting options have been set. > - 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. Ah you mean something like : options = GDALTranslateParseOptions("-outsize 150% 150%"); outDS = GDALTranslate("out.tif", inDS, options) Hum yes maybe that could ease the conversion, but that would also put in stone the current syntax of the utilities at the library level. > - Can we get away from 0/FALSE and TRUE/1 for bools in in C++. e.g. > psOptions->bQuiet The API is intended to be C callable, so bool isn't possible as a type. Even > > -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 -- 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