<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hi Hiroshi,</p>
    <p>I tried to test you solution:</p>
    <blockquote>
      <p>$ git clone --depth 1 <a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal.git">https://github.com/miurahr/gdal.git</a></p>
      <p>$ cd gdal/</p>
      <p>$ mkdir build</p>
      <p>$ cd build</p>
      <p>$ cmake ..</p>
      <p>-- The C compiler identification is AppleClang 9.0.0.9000038</p>
      <p>[ Skipped ...]</p>
      <p>CMake Error at
/Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137
        (message):<br>
          Could NOT find QHULL (missing: QHULL_LIBRARY
        QHULL_INCLUDE_DIR)<br>
        Call Stack (most recent call first):<br>
         
/Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
        (_FPHSA_FAILURE_MESSAGE)<br>
          cmake/FindQHULL.cmake:41 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)<br>
          gdal/alg/CMakeLists.txt:139 (find_package)<br>
        <br>
        <br>
        -- Configuring incomplete, errors occurred!</p>
    </blockquote>
    <p><br>
    </p>
    <p>The QHULL is not mandatory for GDAL build and should not stop
      configuring at that moment.</p>
    <p><br>
    </p>
    <p>Fast review you solution:</p>
    <p>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.<br>
    </p>
    <p>2. Loose some drivers (for example GPKG) as of result manually
      added here
(<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/CMakeLists.txt">https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/CMakeLists.txt</a>)
      - in compare of my idea automatically add drivers
(<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt">https://github.com/nextgis-borsch/lib_gdal/blob/master/drivers/vector/CMakeLists.txt</a>)<br>
    </p>
    <p>3. In GML driver you add EXPAT and Xerces simultaneously - as I
      remember this options are mutually exclusive (may be I'm wrong
      here)</p>
    <p>4. There are mandatory drivers which may be disabled in your
      solution (GeoJSON, ESRI Shape, Map Info ...)</p>
    <p>5. There are  drivers which cannot be disabled in your solution
      but this option must be (ilwis, r, til, saga, <span style="color: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: pre; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">couchdb </span>...)</p>
    <p>6. Again dependency problems. For example plscene, plmosaic
      depends on CURL, but there is no check if CURL is found
(<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/plscenes/CMakeLists.txt">https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/ogr/ogrsf_frmts/plscenes/CMakeLists.txt</a>).
      Rasterlite ans OSM drivers depends on SQLite, ...<br>
    </p>
    <p>7. Self driver dependency - for example mbtiles depends on GPKG
      and also on SQLite but no checks exist
(<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/frmts/mbtiles/CMakeLists.txt">https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/frmts/mbtiles/CMakeLists.txt</a>) 
      <br>
    </p>
    <p>8. A lot of command line utilities not build - gdamanage,
      gdalenhance, gnmmanage, gdalsrsinfo ...)</p>
    <p>9. Your make system checks via configure.cmake in port directory
(<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/port/CMakeLists.txt#L32">https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/port/CMakeLists.txt#L32</a>)
      as the result you hides the variables set by CMake from other
      parts of build (ogr, frmts, apps, etc).</p>
    <p>10. Hardcoded paths - for example
<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/blob/compile_with_cmake/CMakeLists.txt#L38">https://github.com/miurahr/gdal/blob/compile_with_cmake/CMakeLists.txt#L38</a></p>
    <p>11. No summary output after configure.</p>
    <p>12. Install paths on Windows are strange
(<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/CMakeLists.txt#L207-L224">https://github.com/miurahr/gdal/blob/compile_with_cmake/gdal/CMakeLists.txt#L207-L224</a>).
      It mast be some logic (as in my solution) or let CMake choose the
      right paths.</p>
    <p><br>
    </p>
    <p>I would like to note that my solution
      (<a class="moz-txt-link-freetext" href="https://github.com/nextgis-borsch/lib_gdal">https://github.com/nextgis-borsch/lib_gdal</a>) 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.  <br>
    </p>
    <p> <br>
    </p>
    <pre class="moz-signature" cols="72">Best regards,
    Dmitry</pre>
    <div class="moz-cite-prefix">28.10.17 17:52, Hiroshi Miura пишет:<br>
    </div>
    <blockquote type="cite"
      cite="mid:445e75b0-2a22-9034-a048-961255ae1174@linux.com">
      <pre wrap="">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:
</pre>
      <blockquote type="cite">
        <pre wrap="">
As Even said it make sense to move discussion from this ticket (<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/ticket/7080">https://trac.osgeo.org/gdal/ticket/7080</a>) to the list.

</pre>
      </blockquote>
      <pre wrap="">
The ticket (<a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/ticket/7080">https://trac.osgeo.org/gdal/ticket/7080</a>) is my proposal.
I put it because there are significant improvements in CMake ecosystem in recent days.

-  CMake support in Visual Studio 2017.
  (<a class="moz-txt-link-freetext" href="https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/">https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/</a>)
      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.

</pre>
      <blockquote type="cite">
        <pre wrap="">Finally:

Find the link to page with the CMake in GDAL discussion - <a class="moz-txt-link-freetext" href="https://trac.osgeo.org/gdal/wiki/CMake">https://trac.osgeo.org/gdal/wiki/CMake</a>

</pre>
      </blockquote>
      <pre wrap="">
Wiki news point <a class="moz-txt-link-freetext" href="https://github.com/aashish24/gdal-svn/tree/cmake4gdal">https://github.com/aashish24/gdal-svn/tree/cmake4gdal</a>  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.
<a class="moz-txt-link-freetext" href="https://github.com/miurahr/gdal/tree/compile_with_cmake">https://github.com/miurahr/gdal/tree/compile_with_cmake</a>

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

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>