[gdal-dev] About CMake build again

Dmitry Baryshnikov bishop.dev at gmail.com
Sun Oct 29 08:30:21 PDT 2017


Hi Hiroshi,

I think that anyhow the current logic of makefile mast be transfer to 
CMake. See the 
https://github.com/OSGeo/gdal/blob/trunk/gdal/configure.ac or how I did 
it in lib_gdal repository. This logic is rather complicated!

About vagrant:

$ vagrant up
bash: vagrant: command not found

Vagrant is not documented dependency and I don't understand how it will 
help me in may building environment and what additional benefits vagrant 
provide to me in compare with autoconf?

I'm sure all steps in any environment, as Mateusz Łoskot wrote, should be:

git clone .../gdal
mkdir build
cd build
cmake ..
apps/gdalinfo --version


Best regards,
     Dmitry

29.10.17 17:27, Hiroshi Miura пишет:
> Hi Dmitry,
>
> On 2017年10月29日 07:21, Dmitry Baryshnikov wrote:
>> Hi Hiroshi,
>>
>> I tried to test you solution:
>>
> Thank you for testing and sharing your experience.
> It is working in progress status. And it is based on different policy with your solution.
>   
> Now I don't write document about a policy and how-to.
>
> In current script assumes 'configuration has a priority over dependency libraries'
> So when user/developer ON the driver, user/developer should install libraries on their own.
>
> I have not done every dependencies  clean yet, but I've been improved.
> You can  use vagrant script that prepares  environment to pass the build.
>
> $ vagrant up
>
> I've tested with LXC container environment on Linux.
>> The QHULL is not mandatory for GDAL build and should not stop configuring at that moment.
>>
> It is hard work for me to determine which driver is mandatory and which is optional.  Also I need to  determine which driver should be  ON in default.
> It would be a simple rule that driver which does not require 3rd party library is ON in default. Otherwise optional.
>
> Every your feedback is valuable to improve script. It would be good PoC activity to know  which approach is preferable  for GDAL dev community.
> I think your solution is to jump to highest level.  My trial is to realize an intermediate step from current source tree.
>
>
> Hiroshi
>
>
>
>

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


More information about the gdal-dev mailing list