Reconsider build system change?
16 messages, 2 to 7 Jul 2011. Started by John Smith.
John Smith (7), Luke Dashjr (3), Douglas Huff (2), Pieter Wuille (2), Matt Corallo, Jeff Garzik
Hello,
Why again did we choose for autotools as future build system instead of cmake?
- CMake generates native build scripts for Make (all platforms), XCode, Visual Studio. Autoconf only does Make.
- CMake has a clearer syntax, m4/autotools is very convoluted
- CMake is very fast
- CMake is supported natively in Qt Creator in the QT SDK, and is used by many other KDE/QT as well as other open source applications. Many people discourage the use of autotools for new projects.
A CMake build system for bitcoin is already integrated into rpcminer, available here:
http://luke.dashjr.org/programs/bitcoin/w/puddinpop-bitcoin-pool.git/tree
JS
Also important: it supports cross compiling:
http://www.cmake.org/Wiki/CMake_Cross_Compiling
JS
On Sat, Jul 2, 2011 at 7:29 AM, John Smith <witchspace81@gmail•com> wrote:
Quoted text (23 lines)
> Hello, > > Why again did we choose for autotools as future build system instead of > cmake? > > - CMake generates native build scripts for Make (all platforms), XCode, > Visual Studio. Autoconf only does Make. > > - CMake has a clearer syntax, m4/autotools is very convoluted > > - CMake is very fast > > - CMake is supported natively in Qt Creator in the QT SDK, and is used by > many other KDE/QT as well as other open source applications. Many people > discourage the use of autotools for new projects. > > A CMake build system for bitcoin is already integrated into rpcminer, > available here: > > http://luke.dashjr.org/programs/bitcoin/w/puddinpop-bitcoin-pool.git/tree > > JS >
I dont think anyone really made a conscious decision one way or the other, someone submitted an autotools patch and thus people started talking about when we were going to merge autotools. That said, the autotools stuff needs redone before it would be merged anyway. So it would be up to whoever writes the build system. However, autotools is more standard than CMake, and since its a shell script, you dont have to install CMake which doesnt come standard on almost any distros (AFAIK).
Matt
On Sat, 2011-07-02 at 08:13 +0000, John Smith wrote:
Quoted text (40 lines)
> > Also important: it supports cross compiling: > > http://www.cmake.org/Wiki/CMake_Cross_Compiling > > JS > > On Sat, Jul 2, 2011 at 7:29 AM, John Smith <witchspace81@gmail•com> > wrote: > Hello, > > Why again did we choose for autotools as future build system > instead of cmake? > > - CMake generates native build scripts for Make (all > platforms), XCode, Visual Studio. Autoconf only does Make. > > - CMake has a clearer syntax, m4/autotools is very convoluted > > - CMake is very fast > > - CMake is supported natively in Qt Creator in the QT SDK, and > is used by many other KDE/QT as well as other open source > applications. Many people discourage the use of autotools for > new projects. > > A CMake build system for bitcoin is already integrated into > rpcminer, available here: > > http://luke.dashjr.org/programs/bitcoin/w/puddinpop-bitcoin-pool.git/tree > > JS > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge•net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Sat, Jul 2, 2011 at 11:30 AM, Matt Corallo <bitcoin-list@bluematt•me>wrote:
Quoted text (4 lines)
> would be up to whoever writes the build system. However, autotools is > more standard than CMake, and since its a shell script, you dont have to > install CMake which doesnt come standard on almost any distros (AFAIK). >
CMake is also very standard, used by many projects, and is available in many distros.
For debians it's as simple as apt-get install cmake, which is not a big problem as you need to install the other dependencies (such as boost) as well to build.
Fedora/redhat also seems to have the package 'cmake'. I don't think there is any modern distro that doesn't have it as a package.
JS
On Saturday, July 02, 2011 3:29:04 AM John Smith wrote:
Quoted text (2 lines)
> Why again did we choose for autotools as future build system instead of > cmake?
I don't really care much either way, but cmake doesn't follow the standard build procedure (./configure && make && make install), though I imagine ./configure could be emulated with some script.
On Sat, Jul 2, 2011 at 2:50 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (8 lines)
> On Saturday, July 02, 2011 3:29:04 AM John Smith wrote: > > Why again did we choose for autotools as future build system instead of > > cmake? > > I don't really care much either way, but cmake doesn't follow the standard > build procedure (./configure && make && make install), though I imagine > ./configure could be emulated with some script. >
It would change the sequence to
cmake . && make && make install
So a shell script named 'configure' that starts 'cmake .' is the most easy case :-) Probably it'd also need to pass through some command line args, for example --prefix.
JS
On Saturday, July 02, 2011 12:50:14 PM John Smith wrote:
Quoted text (16 lines)
> On Sat, Jul 2, 2011 at 2:50 PM, Luke-Jr <luke@dashjr•org> wrote: > > On Saturday, July 02, 2011 3:29:04 AM John Smith wrote: > > > Why again did we choose for autotools as future build system instead of > > > cmake? > > > > I don't really care much either way, but cmake doesn't follow the > > standard build procedure (./configure && make && make install), though I > > imagine ./configure could be emulated with some script. > > It would change the sequence to > > cmake . && make && make install > > So a shell script named 'configure' that starts 'cmake .' is the most easy > case :-) Probably it'd also need to pass through some command line args, > for example --prefix.
And --datadir --mandir --randomobscurecrap CXXFLAGS=-O9, etc Don't forget --help listing all the useful options... that's the big thing I miss with CMake-stuff.
Cmake is just as bad as autotools, just with a different syntax and more "buzz" behind it right this second. I don't see any advantage to it over autotools unless you're not familiar with either and even then I wouldn't really call it an advantage. It's just different.
It also requires a dependency that isn't installed by default anywhere, as already mentioned, and is less known outside of some obscure qt/kde circles and so finding people who are familiar with it and are willing to maintain it is more difficult.
Autotools is the devil you know.
You'll probably throw out that mysql and compiz have switched to it, but really, those projects aren't something that should be emulated by anyone. Ever.
On Jul 2, 2011, at 11:50 AM, John Smith wrote:
Quoted text (26 lines)
> On Sat, Jul 2, 2011 at 2:50 PM, Luke-Jr <luke@dashjr•org> wrote: > On Saturday, July 02, 2011 3:29:04 AM John Smith wrote: > > Why again did we choose for autotools as future build system instead of > > cmake? > > I don't really care much either way, but cmake doesn't follow the standard > build procedure (./configure && make && make install), though I imagine > ./configure could be emulated with some script. > > It would change the sequence to > > cmake . && make && make install > > So a shell script named 'configure' that starts 'cmake .' is the most easy case :-) Probably it'd also need to pass through some command line args, for example --prefix. > > JS > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Sat, Jul 2, 2011 at 5:05 PM, Douglas Huff <dhuff@jrbobdobbs•org> wrote:
Quoted text (5 lines)
> Cmake is just as bad as autotools, just with a different syntax and more > "buzz" behind it right this second. I don't see any advantage to it over > autotools unless you're not familiar with either and even then I wouldn't > really call it an advantage. It's just different. >
So, what about native build script generation for other platforms? autotools can only generate makefiles (with at least two intermediate code generation steps), which is quite limited.
IMO cmake is simple and elegant compared to the autotools monster. I don't see why it would be "just as bad". And I have quite some experience with both systems. Autotools is a hell to debug. cmake certainly isn't perfect, but at least it's a leap forward.
It also requires a dependency that isn't installed by default anywhere, as
Quoted text (4 lines)
> already mentioned, and is less known outside of some obscure qt/kde circles > and so finding people who are familiar with it and are willing to maintain > it is more difficult. >
Yes, apart from that only obscure projects such as LLVM, Blender, and OpenCV are using it. Nothing of any importance.
BTW for cmake there is "ccmake" which is even better than configure --help as it offers an interactive interface for configuration.
JS
On Jul 2, 2011, at 12:31 PM, John Smith wrote:
Quoted text (1 line)
> So, what about native build script generation for other platforms? autotools can only generate makefiles (with at least two intermediate code generation steps), which is quite limited.
This would be true if gmake didn't build/run basically everywhere; but, it does.
Quoted text (1 line)
> IMO cmake is simple and elegant compared to the autotools monster. I don't see why it would be "just as bad". And I have quite some experience with both systems. Autotools is a hell to debug. cmake certainly isn't perfect, but at least it's a leap forward.
Don't get me wrong, I'm not defending autotools' design or implementation. It is; however, more ubiquitous and understood by a much wider audience.
Quoted text (1 line)
> BTW for cmake there is "ccmake" which is even better than configure --help as it offers an interactive interface for configuration.
I would say that's actually a mark against cmake. If you need a gui to select build options because your cli doesn't have proper help output something is wrong.
If you're willing to setup and maintain a cmake build environment I wouldn't say it should be rejected outright. Speculating about it without an implementation to compare seems like a waste of time.
Especially when jaromil already has a mostly-functional autotools setup. It needs tweaking still and some changes to catch up and rebase, but it works. He also already did the tedious work to rearrange the source tree to make adding any auto-configuration tool for the build environment easy to drop in place. (Which is already merged.)
On Sat, Jul 2, 2011 at 5:45 PM, Douglas Huff <dhuff@jrbobdobbs•org> wrote:
Quoted text (8 lines)
> On Jul 2, 2011, at 12:31 PM, John Smith wrote: > > So, what about native build script generation for other platforms? > autotools can only generate makefiles (with at least two intermediate code > generation steps), which is quite limited. > > This would be true if gmake didn't build/run basically everywhere; but, it > does. >
It doesn't for the native build systems on at least Windows and OSX. Yes, you can get gmake to run, but it's a hack.
Quoted text (4 lines)
> I would say that's actually a mark against cmake. If you need a gui to > select build options because your cli doesn't have proper help output > something is wrong. >
You don't need to use the UI. It's just a convenience. Command line can simply be used if you want.
Quoted text (4 lines)
> If you're willing to setup and maintain a cmake build environment I > wouldn't say it should be rejected outright. Speculating about it without an > implementation to compare seems like a waste of time. >
As I said in my opening post, there *is* a cmake build system implemented for bitcoin.
JS
On Saturday, July 02, 2011 2:03:49 PM John Smith wrote:
Quoted text (2 lines)
> As I said in my opening post, there *is* a cmake build system implemented > for bitcoin.
puddinpop's stuff is all ancient/obsolete. If you want people to consider it, you should probably make a new branch.
On Sat, Jul 02, 2011 at 07:29:04AM +0000, John Smith wrote:
Quoted text (4 lines)
> Hello, > > Why again did we choose for autotools as future build system instead of > cmake?
I have no preference for any particular project build system. If a system * is easy enough to set up (included in standard repositories, eg.) * allows building of the bitcoin codebase on several linux distro's * does cross-compilation to windows * supports osx * is easy to maintain * it is not too hard to adapt other GUI's to use it (bitcoin-qt, maybe others as well, i hear about a cocoabitcoin?) * gets implemented and tested to support all of the above .. i have no problem with choosing that system for future versions.
On Sun, Jul 03, 2011 at 12:44:17PM +0200, Pieter Wuille wrote:
Quoted text (10 lines)
> I have no preference for any particular project build system. If a system > * is easy enough to set up (included in standard repositories, eg.) > * allows building of the bitcoin codebase on several linux distro's > * does cross-compilation to windows > * supports osx > * is easy to maintain > * it is not too hard to adapt other GUI's to use it (bitcoin-qt, > maybe others as well, i hear about a cocoabitcoin?) > * gets implemented and tested to support all of the above > .. i have no problem with choosing that system for future versions.
Other opinions? Someone actually interested in writing a cmake configuration for bitcoin?
On Thu, Jul 7, 2011 at 4:49 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
Quoted text (14 lines)
> On Sun, Jul 03, 2011 at 12:44:17PM +0200, Pieter Wuille wrote: >> I have no preference for any particular project build system. If a system >> * is easy enough to set up (included in standard repositories, eg.) >> * allows building of the bitcoin codebase on several linux distro's >> * does cross-compilation to windows >> * supports osx >> * is easy to maintain >> * it is not too hard to adapt other GUI's to use it (bitcoin-qt, >> maybe others as well, i hear about a cocoabitcoin?) >> * gets implemented and tested to support all of the above >> .. i have no problem with choosing that system for future versions. > > Other opinions? Someone actually interested in writing a cmake configuration > for bitcoin?
autotools is indeed "the devil we know" which works automatically on all supported platforms save VC++ It is also the easiest to package, as all distros already have macros and scripts specifically designed to integrate autotools packages into their package build systems. cmake simply does not have that level of uptake.
Hello Pieter,
Other opinions? Someone actually interested in writing a cmake configuration
Quoted text (2 lines)
> for bitcoin? >
I'm willing to do it, but the priority is not that high.
I'm currently sticking with qmake, as apart from boost library name auto-detection, I had no problems with it and it works well enough for a relatively small project such as bitcoin.
JS