On Tue, May 31, 2016 at 6:23 PM, Even Rouault
wrote:
> Le mardi 31 mai 2016 17:31:06, Rashad Kanavath a écrit :
> > On Tue, May 31, 2016 at 4:06 PM, Even Rouault <
> even.roua...@spatialys.com>
> >
> > wrote:
> > > > On 2016-05-31 8:46 AM, alex wrote:
> > > > > Hi Dmitry and others,
> > > > >
> >
Le mardi 31 mai 2016 17:31:06, Rashad Kanavath a écrit :
> On Tue, May 31, 2016 at 4:06 PM, Even Rouault
>
> wrote:
> > > 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 pro
Hello Jeff,
On Tue, May 31, 2016 at 4:20 PM, Jeff McKenna wrote:
> On 2016-05-31 11:06 AM, Even Rouault wrote:
>
>>
>> Jeff,
>> It sounds your issue with cmake is more mapscript not receiving attention,
>> rather than a defect from cmake itself, right ? I've used cmake to build
>> QGIS
>> on Lin
On Tue, May 31, 2016 at 4:06 PM, Even Rouault
wrote:
> > 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 t
On 2016-05-31 11:06 AM, Even Rouault wrote:
Jeff,
It sounds your issue with cmake is more mapscript not receiving attention,
rather than a defect from cmake itself, right ? I've used cmake to build QGIS
on Linux & Windows and can't recall any particular issue I can really
attribute to cmake (bes
> 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 o
>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 st
Again, I can only speak from experience. I wish that magically I am
wrong for GDAL, and cmake on Windows is maintained for each and every
GDAL driver :) (whoa that is a big wish)
-jeff
Jeff,
Life doesn't have to be so painful with Cmake on Windows. For example in
GMT we use a option
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 dependen
I build 32 & 64 Windows versions for quite some time now and would be
interested in Cmake if I were to start now but since the nmake works so
well for me (plus dependencies) I don't really care about a replacement.
Joaquim
[Dmitry Baryshnikov]
The work is done taking into considerations th
On 2016-05-31 9:24 AM, Damian Dixon wrote:
I'm going to take the slightly opposing view...
I would prefer CMake to be supported particularly for generating WIndows
builds as the nmake build is painful to configure and maintain. I spent
ages getting our original build working with the configurati
I'm going to take the slightly opposing view...
I would prefer CMake to be supported particularly for generating WIndows
builds as the nmake build is painful to configure and maintain. I spent
ages getting our original build working with the configurations I needed,
way more time than I expected.
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 agre
>[Dmitry Baryshnikov]
>
>The work is done taking into considerations this link:
>https://trac.osgeo.org/gdal/wiki/CMake
>Also, there were some ideas about gdal source code reorganisation in
>dev-list.
>This is second turn of cmakefication of GDAL.
>The lib_gdal repository synced with gdal trunk per
Hi Alex,
The work is done taking into considerations this link:
https://trac.osgeo.org/gdal/wiki/CMake
Also, there were some ideas about gdal source code reorganisation in
dev-list.
This is second turn of cmakefication of GDAL.
The lib_gdal repository synced with gdal trunk periodically (there
>> [Alex]
>> Is there a convention about where to place and how to name the win32 and
>x64
>> libraries and include directories when building for both platforms on
>> Windows?
>>
>> Especially, I would like CMake's FindGDAL
>> (https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to
>
Hi,
It seems to me there is no standard install path on Windows, so search
GDAL is tricky.
CMake can register package in registry and so find GDAL, but GDAL have
to be CMaked too.
You may try our CMake GDAL (https://github.com/nextgis-borsch/lib_gdal).
In your project only need to add find_an
Hi,
Is there a convention about where to place and how to name the win32 and x64
libraries and include directories when building for both platforms on
Windows?
Especially, I would like CMake's FindGDAL
(https://cmake.org/cmake/help/v3.0/module/FindGDAL.html) to be able to find
the correct paths
18 matches
Mail list logo
