[nanomsg] Re: Simplifying CMake build
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 30 Aug 2013 07:15:34 -0700
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.
Other related posts:
