[nanomsg] Re: Simplifying CMake build
- From: Sergei Nikulov <sergey.nikulov@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 30 Aug 2013 11:27:42 +0400
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.
> > > 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.
--
Best Regards,
Sergei Nikulov
Other related posts:
