+1 to what Howard said.
Two thoughts... (and I'm not saying CMake is any worse than autoconf)
Alternative build systems:
I co-maintain (mostly just me) a bazel build of GDAL (including autotest2,
expat, geos, hdf4, hdf5, hdfeos, kakadu, libgeotiff, libgif, libpng,
libtiff, netcdf, jpeg, proj, sq
Larry,
I agree that CMake brings some nice and useful features to the table. We
use it for PDAL, but we started out with CMake so there was no migration
that needed to be made.
CMake for GDAL is a project sustainment issue much more than a
technology switch and a patch. A person or a group of per
Hi All,
Apologies for top-posting, albeit the thread has stopped for ~month.
While I have not contributed that much to the GDAL project over the years,
I have build it a LOT (mostly on Win and macOS [0]). Switching to CMake
would be a good future-proof, cross-platform move, even if it is overly
v
On 30 October 2017 at 23:14, Even Rouault wrote:
>
> Trying to sum up my thoughts on this topic and answering to various points
> raised in this discussion thread:
>
> - I believe a relevant question to ask to ourselves would be:
> "imagine that GDAL would come without any build system at all, wha
Hi Even,
31.10.17 1:14, Even Rouault пишет:
Hi,
Trying to sum up my thoughts on this topic and answering to various points
raised in this
discussion thread:
- I believe a relevant question to ask to ourselves would be: "imagine that
GDAL would come
without any build system at all, what is th
Hi,
Trying to sum up my thoughts on this topic and answering to various points
raised in this
discussion thread:
- I believe a relevant question to ask to ourselves would be: "imagine that
GDAL would come
without any build system at all, what is the one that we would add" ? Ok,
that's a bit
Xcode builds, targeting both macOS and iOS, are my primary concern. I have to
use CMake for MySQL and JPEG2000. MySQL is only for server-side work and
testing because licensing issues keep it out of any distributed products.
JPEG2000 works fine. I have tried and failed to get the current, CMake-
Mateusz Loskot kirjoitti 30.10.2017 klo 11:24:
On 30 October 2017 at 10:06, Dmitry Baryshnikov wrote:
Also there is one big problem for me in #7080 - this is third build system
additionally to GNUMakefile, makefile.vc. And now CMakeLists.txt must be
supported too. Three files which must be syn
On 30 October 2017 at 10:42, Dmitry Baryshnikov wrote:
>
> If really "there is no plan or even will for such switch in GDAL" I think
> nothing to discuss here.
I indicated that it is "AFAIU".
I may be wrong.
Personally, I gave up about CMake for GDAL and I use the official build systems.
Luckily
Hi Mateusz,
If really "there is no plan or even will for such switch in GDAL" I
think nothing to discuss here.
The ticket #7080 should be closed and let's continue to live with
current developing approach.
Which solution, my or Hiroshi, will more popular show the time.
Best regards,
Dm
On 30 October 2017 at 10:06, Dmitry Baryshnikov wrote:
>
> Also there is one big problem for me in #7080 - this is third build system
> additionally to GNUMakefile, makefile.vc. And now CMakeLists.txt must be
> supported too. Three files which must be synced each other with and taking
> into cons
Hi Alexander,
CMake scripts from #7080 have no logic presented in current building
system (make/autoconf): there are several mandatory drivers, the
optional drivers, and drivers depends from other drivers.
Also there is one big problem for me in #7080 - this is third build
system additionall
Hi Dmitry,
thanks for explanation. I see that there is an option to use system libraries.
Maybe I'm wrong, but this is also possible with current build system and
CMake scripts from #7080. There is an option to build deps by myself and
use them to build GDAL, but again this is also possible with c
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
Hi Kurt,
And how to deal with non Linux builds like Windows MSVC, mac OS XCode etc.?
Best regards,
Dmitry
29.10.17 17:17, Kurt Schwehr пишет:
While autoconf isn't pretty, it has done me the least amount of harm of any
of the major build systems. Without patches for the downstream packager
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
While autoconf isn't pretty, it has done me the least amount of harm of any
of the major build systems. Without patches for the downstream packagers
and CI (travis/appveyor), I would be -1. e.g. debian/ubuntu,
redhat/centos, macport/brew/fink, and others
With those patches, I'm -0.
BTW, It's no
Hi Alexander,
Please read carefully that I wrote before. There are 3 options:
1. Build gdal with all dependencies getting them from github
(WITH_EXTERNAL). Preferable for Windows
2. Build gdal using the system libraries. Preferable for Linux
3. Build gdal using the dependency libra
While I'm not GDAL developer or regular contributor (submitted only
few patches),
but still often build GDAL trunk on WIndows and Linux, and less often on Mac.
Personally I think that solution proposed in
https://trac.osgeo.org/gdal/ticket/7080
is more preferable. It does not require *all* depende
Hi John,
The CMake don't required complete restructure the GDAL project. But I
think this changes needed to fit new classes inheritance introduced in
GDAL 2.0. And new sources structure more closer to CMake needs.
Also I would like to note that I have only positive experience with
CMake, esp
Hi Brad.
Yes you are right. Just do this steps:
|git clone https://github.com/nextgis-borsch/lib_gdal.git gdal cd gdal
mkdir build cd build cmake .. cmake --build .|
Some discussion was in this ticket
(https://github.com/nextgis-borsch/lib_gdal/issues/13).
There are 3 scenarios supported b
I have my own build system for GDAL and its dependencies. It uses whatever
build system each project uses. CMake is, by far, the most problematic.
Luckily, I can still use the original autotools-based KML.
If I understand correctly, CMake is going to require a complete restructuring
of the proj
Is there a way to invoke that “do all the dependency work for me”
(`find_anyproject`) from the cmake command line?
So if I clone your lib_gdal repo, it could build GDAL and any required
dependencies?
Brad
___
gdal-dev mailing list
gdal-dev@lists.os
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.938
[ Skipped ...]
CMake Error at
/Applications/CMake.app
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 (
Hi,
As Even said it make sense to move discussion from this ticket
(https://trac.osgeo.org/gdal/ticket/7080) to the list.
First of all I would like to make small introduction to Borsch project.
Here it is some useful links:
* Borsch repository: https://github.com/nextgis-borsch/borsch
26 matches
Mail list logo
