[nanomsg] Re: Simplifying CMake build
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 30 Aug 2013 08:02:12 -0700
On Friday, August 30, 2013 11:27:42 AM Sergei Nikulov wrote:
> Alex,
>
>
> 2013/8/30 Alex Elsayed <eternaleye@xxxxxxxxx>
>
> > 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.
>
> Looks like you've mixed build and packaging.
>
> About dependency from qt. It is completely false.
> Qt is not required for cmake.
> cmake-gui does, but it another tool. You can check it with your linux
> package manager.
Actually, I was trying to clear up what seemed to be a confusion over build
and packaging.
The chain of events is:
The developer starts with the code in git. You tag a release, then:
autotools) Run autoconf + automake
cmake) Do nothing
and then you have a source tarball. This is the step that in autotools
requires autotools itself along with m4 and perl
The user (or distro packager) downloads the source tarball. They then:
autotools) run configure && make
cmake) run cmake && make
This is where cmake is needed on the end user machines (some confusion in this
discussion may have arisen from me assuming that the end user was building
this themselves, rather than using a distro package). In autotools, this only
requires sh/cc/ld/sed.
Splitting it into two phases is what allows autotools to have such a small
dependency list for the end user or distro packager.
Also, yes, the qt stuff is a separate tool. Many distros split it into a
separate package. However, it is built as part of the cmake build process - on
gentoo and exherbo, building it is enabled by turning on a useflag or option
(these are source distros, and thus don't split up the upstream package nearly
as readily since it would require running the build twice and then throwing
part away).
Binary distros can split it out into another package, but that's more akin to
how they split out -devel packages than it actually being a separate thing.
> > > > 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.
>
> I don't understand why all already existing platforms was cut off.
>
> I suggest your follow curl way.Use autoconf/automake as primary and support
> it.
>
> But leave cmake as it is. Developers who need it will support existing
> scripts.
Because autotools already serves the platforms that aren't windows (although
the point about Xcode is valid), and thus maintaining cmake on those platforms
going forward was a form of technical debt. It didn't add enough value to be
worth the fact that every single buildsystem change would be twice as much
work, because it'd have to be sure that both were updated and tested to
perform identically on platforms they both supported.
The amount of work an additional buildsystem introduces isn't linear; it's
combinatorial with the number of possible build-time options.
Other related posts:
