[gdal-dev] About CMake build again

[Dmitry Baryshnikov]

Hi Hiroshi,

I tried to test you solution:

    $ git clone --depth 1 https://github.com/miurahr/gdal.git

    $ cd gdal/

    $ mkdir build

    $ cd build

    $ cmake ..

    -- The C compiler identification is AppleClang 9.0.0.9000038

    [ Skipped ...]

    CMake Error at
    /Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137
    (message):
       Could NOT find QHULL (missing: QHULL_LIBRARY QHULL_INCLUDE_DIR)
    Call Stack (most recent call first):
    /Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
    (_FPHSA_FAILURE_MESSAGE)
       cmake/FindQHULL.cmake:41 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
       gdal/alg/CMakeLists.txt:139 (find_package)


    -- Configuring incomplete, errors occurred!


The QHULL is not mandatory for GDAL build and should not stop 
configuring at that moment.


Fast review you solution:

1 Don't see Python 2/3 support (CMake will choose default Python). How 
to configure to build Python 2 or Python 3 bindings? Don't see Python 
bindings install steps.

2. Loose some drivers (for example GPKG) as of result manually added 
here 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/CMakeLists.txt) 
- in compare of my idea automatically add drivers 
(https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt)

3. In GML driver you add EXPAT and Xerces simultaneously - as I remember 
this options are mutually exclusive (may be I'm wrong here)

4. There are mandatory drivers which may be disabled in your solution 
(GeoJSON, ESRI Shape, Map Info ...)

5. There are  drivers which cannot be disabled in your solution but this 
option must be (ilwis, r, til, saga, couchdb ...)

6. Again dependency problems. For example plscene, plmosaic depends on 
CURL, but there is no check if CURL is found 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/plscenes/CMakeLists.txt). 
Rasterlite ans OSM drivers depends on SQLite, ...

7. Self driver dependency - for example mbtiles depends on GPKG and also 
on SQLite but no checks exist 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/frmts/mbtiles/CMakeLists.txt) 


8. A lot of command line utilities not build - gdamanage, gdalenhance, 
gnmmanage, gdalsrsinfo ...)

9. Your make system checks via configure.cmake in port directory 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/port/CMakeLists.txt#L32) 
as the result you hides the variables set by CMake from other parts of 
build (ogr, frmts, apps, etc).

10. Hardcoded paths - for example 
https://github.com/miurahr/gdal/blob/compile_with_cmake/CMakeLists.txt#L38

11. No summary output after configure.

12. Install paths on Windows are strange 
(https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/CMakeLists.txt#L207-L224). 
It mast be some logic (as in my solution) or let CMake choose the right 
paths.


I would like to note that my solution 
(https://github.com/nextgis-borsch/lib_gdal) successfully builds on 
Windows (MSVC), Ubuntu, Mac OS, Android, iOS (in our build environment). 
Also for last two OS you need the special toolchains and dependency must 
support them too.  All check for dependencies are present in already 
cmaked drives, all command line utilities build, also bindings and 
pythons scripts installs in right places. It rather configurable via 
command line options or CMake GUI.


Best regards,
     Dmitry

28.10.17 17:52, Hiroshi Miura пишет:
> Hi,
>
> Dmitry, Thank you for starting the thread.
> I'm Hiroshi, a newbie as user and dev of GDAL. I'm OSM mapper.
>
> On 2017/10/28 06:06, Dmitry Baryshnikov wrote:
>> As Even said it make sense to move discussion from this ticket (https://trac.osgeo.org/gdal/ticket/7080) to the list.
>>
> The ticket (https://trac.osgeo.org/gdal/ticket/7080) is my proposal.
> I put it because there are significant improvements in CMake ecosystem in recent days.
>
> -  CMake support in Visual Studio 2017.
>    (https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/)
>        VS17 bundles CMake 3.9 into their tool chains.
>        It helps editing code and debugging a C/C++ project with CMake.
>
> - JetBrains CLion only supports CMake.
>     CLion appeared in 2014.   Current CLion 2017.2 bundles CMake 3.8.
>
>
> When I made a small contribution for GML driver recently,
> I had a frustration to make changes on GDAL source tree.
> If changing code and  unit test cycle become speedy, it would be better.
>
> It is because I want to improve a development experience using C/C++ IDE.
> After short research, I reached a conclusion to use CMake with GDAL source tree,
> and work with CLion IDE on my Linux laptop.
>
>> Finally:
>>
>> Find the link to page with the CMake in GDAL discussion - https://trac.osgeo.org/gdal/wiki/CMake
>>
> Wiki news point https://github.com/aashish24/gdal-svn/tree/cmake4gdal  as a  repository.
>
> I tried it and catch up current GDAL  tree.
> Unfortunately I didn't know Borsch project,
> and a dependency issue discussed here in some years ago.
>
> I eventually  updated cmake4gdal scripts to be able to read from CLion IDE on Linux/Windows.
> https://github.com/miurahr/gdal/tree/compile_with_cmake
>
> It can build a library with many drivers, python/perl bindings on Linux
> and update vagrant script  to prepare clean compilation environment.
> It also run autotest from CMake by specifying --target autotest
>
> VS17 preview 2.0 can open this source tree as a VS native project on Windows10.
> (compilation is not succeed)
>
> Hiroshi Miura
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171029/33c1e1f8/attachment.html>