While autoconf isn't pretty, it has done me the least amount of harm of any of the major build systems. Without patches for the downstream packagers and CI (travis/appveyor), I would be -1. e.g. debian/ubuntu, redhat/centos, macport/brew/fink, and others
With those patches, I'm -0. BTW, It's not unreasonable to have separate build systems. It's work, but very doable. I maintain a bazel build environment. I have to notice add or deletes of files in upstream, but it's been working for more than a decade. On Sat, Oct 28, 2017 at 11:11 PM, Alexander Bruy <alexander.b...@gmail.com> wrote: > While I'm not GDAL developer or regular contributor (submitted only > few patches), > but still often build GDAL trunk on WIndows and Linux, and less often on > Mac. > > Personally I think that solution proposed in > https://trac.osgeo.org/gdal/ticket/7080 > is more preferable. It does not require *all* dependencies to be build > with cmake, > it does not require maintaining forks with special directory structure for > *all* > dependencies, it plays well with conventions/packages provided on all > systems > out of the box. Maybe borsch is good for in-house use when all stack > is build from > scratch but it is not suitable for real-world use cases. > > Of course, #7080 is not ideal, there are some issues, but as I understand > the > work is not over and most (if not all) issues can be solved. > > Just my 2c. > > 2017-10-28 0:06 GMT+03:00 Dmitry Baryshnikov <bishop....@gmail.com>: > > Hi, > > > > As Even said it make sense to move discussion from this ticket > > (https://trac.osgeo.org/gdal/ticket/7080) to the list. > > > > First of all I would like to make small introduction to Borsch project. > Here > > it is some useful links: > > > > * Borsch repository: https://github.com/nextgis-borsch/borsch > > > > * Presentation on FOSS4G 2016: > > http://nextgis.ru/wp-content/uploads/2016/08/NextGIS-Borsh- > presentation.pdf > > > > * GDAL repository adapted for Borsch: > > https://github.com/nextgis-borsch/lib_gdal > > > > Shortly speaking Borsch is 3 CMake scripts which add ability to include > > dependence library in one line of code. > > > > It looks like: > > > > find_anyproject(TIFF REQUIRED) > > > > Certainly developer can add additional parameter to configure dependency > in > > find_anyproject function. > > > > Inside find_anyproject work 2 cases: > > > > 1. First of all (by default, but can be overridden) CMake searches host > > system for dependency library (headers and lib files). This is usual > CMake > > find_package (https://cmake.org/cmake/help/ > v3.0/command/find_package.html) > > with some additional logic to try different options for hard cases (like > > Qt). > > > > 2. If library not found, find_anyproject can get the sources or prebuild > > library from github. > > > > So the GDAL or any other library can be build the normal way, but > developer > > have additional features to configure build all libraries with one > compiler > > and one set of compiler/linker settings (with some limits). Such way we > can > > have rather complicated scenarios to build GDAL and dependencies. > > > > Here it is several examples of benefits of this approach: > > > > 1. NextGIS Mobile SDK v3. SDK based on GDAL and need it in one library > for > > iOS as *.framework and for Android as *.so (arm7, arm64, i386, x86_64 > > architecture). I build all dependencies include GDAL statically and link > in > > one fat library. The all code that do it: > > https://github.com/nextgis/nextgis_datastore/blob/master/ > cmake/extlib.cmake#L118-L236 > > > > By the way the library also builds on Linux and Mac OS (Windows under > > development) and CMake try to use existed in host system libraries. If > CMake > > find GDAL in host system it will use it and all (-DENABLE_PLSCENES=OFF > ... ) > > will be ignored as it already build with another parameters. > > > > 2. Build GDAL Windows standalone installer and GDAL Ubuntu ppa: > > https://github.com/nextgis/ppa/blob/master/gdal/master/debian/rules > > > > 3. Build QGIS > > (https://github.com/nextgis/nextgisqgis/blob/master/CMakeLists.txt#L149 > ), > > PostGIS > > (https://github.com/nextgis-borsch/postgis/blob/master/ > CMakeLists.txt#L165), > > Formbuilder > > (https://github.com/nextgis/formbuilder/blob/master/cmake/ > extlib.cmake#L53-L173) > > > > This is main Borsch features. > > > > > > There are some additional conventions like: > > > > * I modify all libraries included into Borsch repository to install > on > > unix-like paths. For Linux this is usual, for Windows and Mac OS this > let us > > to use Qt installer framework an install software mach similar like on > > Linux. This is about target "install" which is vary on different > libraries > > (CMake has it own conventions about it). This is not mandatory for Borsch > > itself but useful. CMake can register installed libraries in system > > repository to simplify find them in find_package function. > > > > * CMake get library version from sources in all libraries included > into > > Borsch (if applicable, otherwise set it in CMake script). This is > necessary > > if exact version of library needed. This is not mandatory. One more > benefit > > during building process we can see dependency library version in console. > > > > * We modify all libraries included into Borsch repository to find > > dependencies using find_anyproject. It is simple to use libraries from > our > > borsch repository, but developer can fork them or use any other sources > and > > build systems to have dependency library in it's host system. > > > > One can see this is all very flexible. > > > > > > What about GDAL. > > > > 1. After unification GDALDataset and OGRDatasource current sources tree > is > > not fit for this new logic of GDAL classes. I rearranged sources more > closer > > to GDAL classes and CMake needs. Main changes are moving raster and > vector > > drivers inside drivers folder > > (https://github.com/nextgis-borsch/lib_gdal/tree/master/drivers).This > > simplify situation where different drivers need the same dependency > library > > (libpg, libsqlite, etc.). Also there are several raster/vector drivers > which > > need a separate directory but now presented in ogr or frmts directories. > > There are some bad decisions I made - for example I moved unit tests into > > separate repository - this was a mistake. We will return unit tests back > to > > GDAL repository. > > > > An example of cmake friendly way see > > https://github.com/nextgis-borsch/lib_gdal/blob/master/ > drivers/vector/CMakeLists.txt. > > The driver developer must only create new folder and put CMakeLists.txt > file > > into it. The upper CMake script will find new driver and add it to GDAL > > build. In common cases no need to modify upper CMake scripts. > > > > 2. I remove third-party code from drivers folders (TIFF, GeoTIF, PNG, > JPEG > > etc). All this code are in separate repositories. I don't see the > difference > > to get this code from git pull from main GDAL repository or from the > > separate repository via find_anyproject process. Current GDAL repository > > looks like the https://github.com/nextgis-borsch packed in one > repository. > > > > > > In conclusion: > > > > 1. Borsch added flexible and useful features and not remove existing > > approach > > > > 2. The current cmaked GDAL are in production in my company more than a > year > > on Windows, Linix, Mac OS, iOS, Android. > > > > 3. I'm ready to discuss and improve current solution. Any help are > welcome > > > > 4. I also will be happy to contribute directly or via PR into GDAL trunk > > instead of backporting in both directions improvements that we do in > GDAL . > > > > > > Finally: > > > > Find the link to page with the CMake in GDAL discussion - > > https://trac.osgeo.org/gdal/wiki/CMake > > > > -- > > Best regards, > > Dmitry > > > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Alexander Bruy > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
