[gdal-dev] Building GDAL on Windows 32 and 64 bit

[Dmitry Baryshnikov]

2Jeff

This is the only one example of building GDAL and other libraries and 
this is not CMake problem of MapScript support, but MapServer's team 
priorities.

Building libraries for MS4W is only one activity. But there are lot of 
others which developer may need:

- configure GDAL and dependencies via GUI in crossplatform manner
- configure GDAL and dependencies in make scripts of developer's 
application in crossplatform manner (for example I build my library with 
GDAL and it dependencies for Android/iOS with needed set of drivers and 
options and toolsets, and use the same cmake as for desktop/server)
- build software and dependency with one set of compiler/linker
- generate projects for supported RAD utilities
- etc.

2Alex

The list is silent as we already discussed CMake in GDAL so many times.
There is no problem that two versions of build system exists - original 
and cmake.
All contribution goes to GDAL trunk. Periodically I sync trunk with 
nextgis-borsch/lib_gdal

The borsch cmake scripts are not stable yet and we are still fixing them.
Now I don't see any topic to discuss here.

2All
By the way I'll have a talk about this new build system on FOSS4G Bonn, 
this will be good place to discuss this.

Best regards,
     Dmitry

31.05.2016 15:00, Jeff McKenna пишет:
> On 2016-05-31 8:46 AM, alex wrote:
>>
>> Hi Dmitry and others,
>>
>> I can see that you are making a great effort, and as far as I can 
>> tell with great progress too.
>>
>> Do you know why the rest of the list is silent on this? Are the GDAL 
>> developers not interested in cmakeification or are they in silent 
>> agreement with your approach?
>
> I for one am not interested in 'cmakeification' of GDAL.  For the MS4W 
> community, I build 32 and 64 bit versions, for the full stack of 
> Apache, PHP, MapServer, GDAL (I counted recently and it is now over 
> 200 libraries) - and the few projects that use cmake are the 
> troublesome ones.  (for example, MapServer switched to cmake but no 
> one is maintaining the mapscript parts of cmake, which means I have 
> kept my own makefiles alive, in order to build all of MapServer).
>
> I am very against cmake, I have had terrible experiences.  I am all 
> for sharing our makefiles and making life easier, than using a fancy 
> cmake system that is not maintained.
>
> -jeff
>