Hi John,
The CMake don't required complete restructure the GDAL project. But I
think this changes needed to fit new classes inheritance introduced in
GDAL 2.0. And new sources structure more closer to CMake needs.
Also I would like to note that I have only positive experience with
CMake, especially 3.x (where many things made simpler).
For iOS builds I wrap CMake into the XCode project and used it via
Carthage (see
https://github.com/nextgis/nextgis_datastore/tree/master/opt/ios). This
is not just GDAL, but an example how GDAL can be wrap too.
Best regards,
Dmitry
28.10.17 22:29, John Daniel пишет:
I have my own build system for GDAL and its dependencies. It uses whatever
build system each project uses. CMake is, by far, the most problematic.
Luckily, I can still use the original autotools-based KML.
If I understand correctly, CMake is going to require a complete restructuring
of the project and a complete dependency on CMake for all dependencies. Can
anyone explain how this would improve anything?
With the KML project and others, I have found CMake to be the most complicated
and most problematic build system. When there is a problem, I'm helpless to
resolve it on my own. The people who made the CMake scripts are equally
helpless because they use a different platform. I build on a Mac with Xcode and
target both macOS and iOS. Are the maintainers of the GDAL CMake build scripts
going to have access to same beta versions of all the above that I am using?
I'm not an active member of the mailing list. I've been on different projects
the past couple of years but was looking forward to working on GDAL-based
projects full time next year. CMake will shut me out of the community entirely.
I simply don't have time to master CMake just to build projects that had never
required a similar level of mastery of autotools. Instead, I will be forced to
stay on the last working version I have. I won't be able to contribute any
fixes I make or new features like my boost replacement for GEOS and Spatialite.
If some people like CMake and it works on their platforms, great. Then let
people choose what build tools they want and what they can support on their own
platforms.
John Daniel
Etresoft, Inc.
Sent from my iPhone
On Oct 27, 2017, at 5:06 PM, Dmitry Baryshnikov
<bishop....@gmail.com<mailto:bishop....@gmail.com>> wrote:
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<mailto:gdal-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
