Switch to CMake (was: Native build on Windows using Clang)

DesWurstes commented at 11:17 am on August 31, 2018: contributor

Bitcoin Core can be built on Windows using Clang natively. Currently only a few projects are using this (Chrome since march, Firefox since yesterday). It’d make building for Window easier. Moreover, I’m sure that it’s easier to use than MSYS + MinGW.

There’s only one obstacle:

Autotools does not run on Windows!

What are your opinions on creating a Cmake file? Although the configure.ac is not-so-tiny, the review community is really active here. If I get positive feedback about it, I’d be glad to create the first draft of it. In addition, Cmake files are used more often. Wouldn’t it be great to give the option for builders to choose between autotools and Cmake?

fanquake added the label Windows on Aug 31, 2018

fanquake added the label Build system on Aug 31, 2018

ken2812221 commented at 7:30 pm on August 31, 2018: contributor

Concept ACK. This should be very helpful for those who want to build on Windows.

fanquake commented at 9:17 am on September 2, 2018: member

I’m not really +1 on having to maintain two different build systems simultaneously. Given that most devs here aren’t using Windows, most won’t think to add/adjust any Windows specific Cmake stuff, because they wont notice while compiling (which will likely hold up review).

However, given that Windows has been getting some love tests/compile wise recently, I think a PR is worthwhile to see how complex/hard to maintain this might be.

scravy commented at 10:31 am on September 2, 2018: contributor

When moving to cmake alltogether there would be only one build system which is supported by a zillion IDEs and works on all operating systems.

sipa commented at 10:53 am on September 2, 2018: member

On Sun, Sep 2, 2018, 04:32 Julian Fleischer notifications@github.com wrote:

When moving to cmake alltogether there would be only one build system which is supported by a zillion IDEs and works on all operating systems.

I’m sure there are advantages of one build system over another, and if cmake can replace all supported existing use cases and more, then that sounds like a good deal.

However, it does sound like a monumental task to me. I don’t know much about build systems, so maybe I’m overestimating this, but does this mean we also need to cmakeify libsecp256k1 and libunivalue? Does the depends build need to be modified as well, or can we keep that make based? Do we need to find alternatives to the make based tricks used to run the unit tests in parallel? I’m just concerned that people suggesting moving from one setup to another underestimate the work that went into our current build infrastructure.

ken2812221 commented at 2:53 pm on September 2, 2018: contributor

IMO, we are already maintain 2 different build system(MSVC) which integrate by a weird way (auto-generated by python script). Switching to cmake isn’t going to add the third build system but to replace native MSVC project files to be more readable and easier to edit. If the cmake build system have done, the msvc native *.vcxproj files could be removed immediately. Also, there are more and more projects are switching to cmake because it’s more portable, especially for MSVC and clang-cl support.

DesWurstes commented at 4:12 pm on September 2, 2018: contributor

I’ve opened a UniValue Pull Request: https://github.com/bitcoin-core/univalue/pull/16

will work on Core Cmake soon

but does this mean we also need to cmakeify libsecp256k1 and libunivalue?

Cmake can use Autoconf dependencies; that’s needed for Windows compatibility

Does the depends build need to be modified as well, or can we keep that make based?

Windows has nmake, so that’s not needed, although Cmake can download dependencies.

Do we need to find alternatives to the make based tricks used to run the unit tests in parallel?

no idea

maflcko renamed this:
~~Native build on Windows using Clang~~
Switch to cmake
on Oct 23, 2018

maflcko renamed this:
~~Switch to cmake~~
Switch to CMake (was: Native build on Windows using Clang)
on Oct 23, 2018

jameshilliard commented at 11:36 am on December 31, 2018: contributor

I’d generally recommend against moving away from autotools for this type of project, while autotools syntax is rather archaic/terrible it does do a number of things well that other build systems do not, mostly when it comes to extreme flexibility, portability in addition to properly handling cross-compiliation. We need to be able to cross compile binaries for all targets that we do binary releases for from a linux build system due to gitian. For developers on Windows we do have msvc build support already.

One issue with cmake is that it’s a makefile generator while autoconf is a configure script generator, the configure script created by autoconf is designed to be portable, there isn’t really a direct equivalent with cmake AFAIK. In general autoconf projects are considered easier to work with for people packaging software even though the build system may be somewhat more complex to maintain.

Talkless commented at 5:08 pm on May 28, 2019: none

Do we need to find alternatives to the make based tricks used to run the unit tests in parallel?

It is possible to parallelize tests using ctest [0]. CMake Cookbook example [1] shows that it is possible to group (if needed) tests with costs attached.

We need to be able to cross compile binaries for all targets that we do binary releases for from a linux build system due to gitian.

Are you implying that CMake does not support cross-compilation..? You “just” (heh) define toolchain file. Same CMake Cookbook has example where you build Windows executable from Linux host. See docs [2].

For developers on Windows we do have msvc build support already.

If CMake would generate MSVC projects for us, that would mean maintaining that directory would be no longer needed?

[0] https://cmake.org/cmake/help/v3.14/manual/ctest.1.html [1] https://github.com/dev-cafe/cmake-cookbook/blob/v1.0/chapter-04/recipe-08/using-cost-example/CMakeLists.txt [2] https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html#cross-compiling

sipa commented at 5:33 pm on May 28, 2019: member

@Talkless I’m just listing perhaps nontrivial things that we’ve built based on our existing build system, which would need to be redone for a new build system before we can even consider switching.

jameshilliard commented at 5:35 pm on May 28, 2019: contributor

Are you implying that CMake does not support cross-compilation..?

No, but I find autotools to typically have much better cross compilation support than CMake.

elichai commented at 2:07 pm on July 9, 2019: contributor

Is anyone working on this?

I think trying to switch to a simpler build system is a good idea (assuming the result is actually simpler) And cmake is now a requirement for some stuff(CLion in particular)

maflcko commented at 3:02 pm on July 9, 2019: member

@elichai Not that I am aware of. Also @theuni seems to be working on keeping the dependencies in autotools. IIUC, as a first step they would have to be transitioned to cmake.

See the pull from @theuni

Split sources for easier buildsystem integration https://github.com/bitcoin-core/univalue/pull/19

maflcko commented at 3:03 pm on July 9, 2019: member

And cmake is now a requirement for some stuff(CLion in particular)

You can edit and run Bitcoin Core in Clion, but Clion can’t do the static code analysis.

elichai commented at 3:16 pm on July 9, 2019: contributor

Thanks. I think I succeeded to “hack” CLion to recognize all the files by just adding a dummy CMakeLists file (https://gist.github.com/elichai/60f1a16fdb51aeba9a9de0a5de23738a) (altough the static code analysis still lacks a lot but it does find the declarations for stuff)

looking at @theuni PR it seems like working on CMake is a waste of time (unless someone can really show that the result will be a lot simpler to manage and understand)

chiumichael commented at 6:47 am on October 17, 2019: none

I think it’s worth adding CMake support given the broader c++ community has basically settled on CMake (even Qt6 is switching to it in favor of qmake). It would take quite a bit of time and happen incrementally, but there’s nothing wrong with that and it would allow others not familiar with CMake to understand it better; I’d be more than glad to work on it.

P.S. On a related note, why are some of the dependencies like libsecp256k1 copy and pasted in and not pulled as a submodule?

elichai commented at 7:12 am on October 17, 2019: contributor

@chiumichael it’s not copy-pasted. It’s a git subtree https://manpages.debian.org/testing/git-man/git-subtree.1.en.html

jameshilliard commented at 6:03 pm on October 21, 2019: contributor

If anything meson is probably a better choice than cmake by now and has visual studio support. A number of open source projects such as gnome have been porting to meson from autotools.

chiumichael commented at 6:20 pm on October 21, 2019: none

build2 is interesting too imo

maflcko commented at 1:44 pm on October 22, 2019: member

It appears, meson could also be wrapped into cmake IDEs (https://pypi.org/project/meson-cmake-wrapper/)

elichai commented at 9:14 pm on October 22, 2019: contributor

Sadly if people can’t even agree on a specific “best” build system then the chances of this ever being accepted is pretty low.

I would personally be in favor of switching a build system only if it gives us one of these features:

Reduce the complexity of the build system by a lot (making it easier to maintain and adjust over time)
Reduce the amount of stuff to maintain (i.e. MSVC stuff).
Can show actual real superiority over the current build system (highly doubt that can be the case).

A nice feature but I don’t think that’s enough to switch is somehow faster builds.

sipsorcery commented at 8:55 pm on June 19, 2020: contributor

@fanquake @MarcoFalke imho this issue should be closed pending someone coming up with a cmake PR.

The OP mentions autotools and msys + mingw there is unlikely to be any consideration given to switching the official build system to cmake. Most of the discussion is about switching the current msvc build (which is for developer convenience only and never used to build official binaries) to cmake. That would be possibly be a minor improvement to the current msvc build config and Visual Studio does now have cmake support. Without a PR, even it was for only one of the libraries, this issue is a bit academic.

maflcko commented at 9:01 pm on June 19, 2020: member

The feature request didn’t seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.

maflcko closed this on Jun 19, 2020

bitcoin locked this on Feb 15, 2022

hebasto commented at 3:36 pm on January 3, 2026: member

Bitcoin Core can be built on Windows using Clang natively.

Please see #31507.

Switch to CMake (was: Native build on Windows using Clang) #14118