On Friday, August 30, 2013 10:22:04 AM Sergei Nikulov wrote:
Martin,
2013/8/30 Martin Sustrik <sustrik@xxxxxxxxxx>
Hi Sergei,
1. CMake doesn't work that well for cross-building.
Who said that? What was the exact problem and was it raised in
"cmake-dev" list?
Find the discussion here: https://github.com/250bpm/**
nanomsg/pull/80#issuecomment-**20920440<https://github.com/250bpm/nanomsg/
pull/80#issuecomment-20920440>
AFAIU, it's not a specific bug, rather the overall state of
cross-compilation support in CMake vs. autotools.
It is not true. CMake can be and used for cross compilation.
The issue (which was raised by Luca Barbato IIRC) is that the individual
projects need to do a lot more work to support cross-compilation with CMake
vs. Autotools. It's not that it can't be done; it's that Autotools has a lot
more of the scaffolding built-in.
2. CMake-generated packages have CMake dependency whereas autotools
packages are not dependent on autotools
Could you please provide name for that dependency?
When you unpack the source package you have to do "cmake .", thus cmake
has to be installed.
With autotools, the ./configure script is bundled in the package, so you
don't need autotools installed to build the package.
To my knowledge when you do 'configure', autotools and perhaps m4 has to be
installed :-)
Now what? You have autotools for linux and cmake for windows.
Instead of one tool you've got both.
That's completely false. Running autoconf requires m4 (and autoconf itself),
running automake requires perl (and automake itself), but those *are not run
by the end user*. Those are run when you make the tarball, converting
configure.ac and Makefile.am to configure and Makefile.in.
Running configure to convert Makefile.in to Makefile only requires posix sh, a
working compiler and linker, and I think possibly sed.
In comparison, cmake must be run by the end user, and depending on what got
turned on by the distribution (did you know that cmake has a build option to
make some additional tools that require Qt4 or Qt5?) may have some heavy
dependencies.
I agree with Bruce - if it works why you cut it off?
It was an option - somebody who use it will support it and provide you
with pull request.
I don't think it was intrusive for source code.
It's because of the cost. Actual work needed to prevent bitrot of cmake
build system. If you volunteer to keep it up-to-date and functional all
the
time, we can discuss adding it back.
Can we have both build systems? If somebody find that cmake build is
broken, then he'll fill the bug or pull request in github.
The issue isn't finding the bugs, or whether they are fixable. It's that
fixing them requires effort (a limited resource), and all build systems need
to have the same result on platforms that are supported by more than one.
