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 the one that we would add" ? Ok,
that's a bit silly to
turn the question like that, a more realistic one would be "imagine you're
going to create a
software that will rule over the world, for the 20 next years and beyond, and
should run on
all reasonable platforms, which build system would we use? If the answer is clearly
"cmake",
then it is worth examining if there is not a path that would lead us to that
point.
Similar question: is it an effort that will make GDAL development a bit easier
for new
contributors?
This is clearly for me long ago and this is CMake.
- Must be reasonably friendly for GDAL developers, and for GDAL users (users
here = people
building GDAL, but not actively hacking into its sources). As a user of cmake
on Linux (and
marginally on Windows), my experiences are rather good.
Again want to point about illogical structure of source codes where we
have some drivers in root folder (frmts) and other drivers are deeper
in the sources tree (ogr/ogrsf_frmts). And also we have raster drivers
in ogrsf_frmts - like gpkg, cad (yes I know that they are raster-vector
drivers) and vector drivers are in raster folder frmts, etc.
- the selling points I'd see with cmake would be the possibility of having
ultimately a single
build system, instead of the 2 ones we have. + solving the current lack of
dependency
tracking (speaking here about the mecanism that cause a change in a .h file to
make the
.c/.cpp files that depend on it to be automatically rebuilt). We could add that
by using
automake instead of our home-made GNUmakefile's, but doesn't feel like that's
worth the
effort by itself.
A nice side effect could also be the opportunity to drop some cruft that has
accumulated
over years in the current build systems (supporting ancient library versions
that no longer
make sense)
+ 1
- If we added cmake support in trunk, I think this would only make sense if
(all conditions to
be met)
* we have at least a couple of "champions" to support the effort, and
with an
agreement on how to use cmake as a in-tree build solution. Regarding Borsch, I
think Dmitry
and his team did an impressive work, although I think that for GDAL we would
want a more
"traditional" way of using cmake (in-tree, no particular requirents regarding
how the
dependencies should be made). I'd hope that part of the work done on Borsch (or
at the very
least good ideas and the lessons learnt) could be ported back to such a more
traditional way
(and in a way where that would still be useful for Borsch. Possible win-win ?)
Using the find_anyproject function from Borsch (which is a wrapper
around find_package) instead of find_package this is the only one
requirements for successfully used in Borsch without any hacks (can be
discussed to get win-win). Any others, like conventions about install
paths, versions, naming etc. are optional and can be discussed too.
* growing it from an experimental status to the recommended build
system, once
its completely mature. I'd expect that to require a transition over one or two
release cycles
(one reason for that delay would be that systems ship with a recent enough
version of cmake
regarding the minimum we would require)
* ultimately removing autoconf + nmake support. Clearly we don't want to
support 3 different build systems for the next 20 years.
- Thinking that if there's an agreement to give it a try, the next OSGeo code
sprint ( https://
wiki.osgeo.org/wiki/OSGeo_Code_Sprint_2018 ) could be the opportunity to boost
(no pun
intended) the effort
- I'm puzzled about some of you having apparently completely different feeback
regarding
CMake on the same platform (MacOS). I don't owe a Mac, so I've no informed
opinion on this.
But I see that a software, with a complexity similar to GDAL, like QGIS uses
CMake and it
builds on Linux, Windows and MacOSX
- There wasn't much discussion about support for more exotic targets, like
cross-compiling
for Windows with mingw compiler hosted on Linux. But openjpeg for example has
Travis-CI
targets doing that, so this is at least achievable for a simple library.
- I've no fundamental objection to cmake... nor fundamental enthousiasm for it
or mastering
of it (could say the same about autoconf/automake or nmake. Build systems are
boring
subjects, aren't they ?)
Even
PS: for Ari, try ./configure --enanble-debug for builds with -g and without -O2
;-)
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I working on CMake for GDAL for a long time and ready and willing to
take part in this work. But it is necessary to make all decisions about
how new build system based on CMake should looks like. Now it is not
clear to me.
Should it be RFC based on this letter and
https://trac.osgeo.org/gdal/wiki/CMake or something else?
Best regards,
Dmitry
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
