From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 07 Aug 2024 14:53:07 -0700 Received: from mail-yw1-f191.google.com ([209.85.128.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sboag-0003To-0G for bitcoindev@gnusha.org; Wed, 07 Aug 2024 14:53:07 -0700 Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-650fccfd1dfsf6646077b3.0 for ; Wed, 07 Aug 2024 14:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1723067579; x=1723672379; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=3Bp4nbzKhdS2qA9F7HICwVLRhCQa3+Y+AQZMpDk5jD4=; b=HxnZqQAh/wuwkQPkFJdcYuj7eNAGnZaVXrI2g/stMGyMk6gz7Ps+qYVBTx8UMIaIjR l4TNaHHs2O4RXmO88LgPBO04BblNJXqPosmFC3TV6+OJZW7zw0vTCsxmsupJbsWPIPWz 0vL4TadLRTrznUzy7WDsRc6iRjzU3I9eu4jtBMd8XyjNzHYFZtoAidx8HUs+2pfxaKJ/ pNUmrH0lDxi6iZwCbPCuD4MVEZrDGYGr5JGiktRSzriGhjAJHK718Ia0ULcj5IaQtyc/ 6fAo4lSIYhgkiRYT8sqrSIFQKb03uyAv2cpMLp3qHGTwtsE1gtae3hoDz2UJLBbc/F1B 9B+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coryfields.com; s=google; t=1723067579; x=1723672379; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=3Bp4nbzKhdS2qA9F7HICwVLRhCQa3+Y+AQZMpDk5jD4=; b=UJ0SjXxunW4Zl3tMQIv155VX2QoltFIlT1cu6CTf9aBT6hf8T1zNZvW65qFfmQAhW8 XjpfiNRZ6eRPxVP1nIZHF1IxGqsF40v3IEApdMF/9b3nySDb/oJ3c3sm7doaCcYkPAzx vtrBuy4F5QRS6uYFy/VzY13DPvJaoc/OVSkCEuCVKk3x0uE8+DTsq5+4ur7R38BYYsVK hT+pUxXfZzzJn8DjrJErhBwmyvcPMdsOYZdbMu7cSLBcb3K4YiNyR7jmdNTpn1LUSh5W oWTuHIMXuQDoqw3KpHfwZbHU8EIC0bhFCEvG/OK42ZHwSsrkhqrRR1m9547UD3bL4VvI dWXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723067579; x=1723672379; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=3Bp4nbzKhdS2qA9F7HICwVLRhCQa3+Y+AQZMpDk5jD4=; b=FDtz4PFbPCpbJMQ8FIlqZbLRO5yNK3zTiMoqcN5/BPqbcoZKAcc79dPa/+luGyMEgM qVcin9whfru+XUv4LpFryxJ7N+JmJEWFpArGbZuTUN0ogS5OTMWpycusptFpJS3pB1NG uX3pa1M0DdlsjjSx9Rd4y6iedh8Z2hn0xg7Oa1Y+G4OeztBfCbv0CO6IF0VLSU/F5KVF VU6a1DoZi0+/gwCzeTivu/EoJ0bGe3TQCtQzKYuD+Ln5olDQgvyoUi04KmbVWSj/QMNg K7Ifo1dIMPk4xb+xf0Cnf4v6BK8bdJcYWinmFmDIEIiFi+a6SpMd33PJ1JcAmscVeZEk dHFA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUwVVBTx3Kohyq7vl56zKhyZVOkMGBR4fUdP3xPRB1j9MFqCUotoiKDt60Hofqrr87/rW9B/TSC9PzlL/hXmjidZCC3JsQ= X-Gm-Message-State: AOJu0YxqBRrRieidotxSYMmJClF3+6eVa/slQOnBsDNNaZhX2yfq+/BO 8JEF5yeRnqG+stSZqIj+wtwWeRA/f1rVjs3wu9JBccgUTK9yYY0e X-Google-Smtp-Source: AGHT+IFjPNer6B3HrC5NR0OMv/YZWjxDoYzP0z5EvSsTGZLbA08ehWzB9bVcfY595MOQboOcuSHj4Q== X-Received: by 2002:a25:361f:0:b0:e0b:ce2b:d569 with SMTP id 3f1490d57ef6-e0bde54a238mr18351541276.57.1723067579326; Wed, 07 Aug 2024 14:52:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:1208:b0:e03:b1e4:4018 with SMTP id 3f1490d57ef6-e0e976c923cls415614276.1.-pod-prod-03-us; Wed, 07 Aug 2024 14:52:57 -0700 (PDT) X-Received: by 2002:a05:690c:298:b0:62f:a56a:cee8 with SMTP id 00721157ae682-6895fbdddd7mr3177947b3.3.1723067577595; Wed, 07 Aug 2024 14:52:57 -0700 (PDT) Received: by 2002:a05:690c:24c:b0:627:7f59:2eee with SMTP id 00721157ae682-698a7bede53ms7b3; Wed, 7 Aug 2024 14:47:26 -0700 (PDT) X-Received: by 2002:a05:690c:d:b0:61d:4701:5e66 with SMTP id 00721157ae682-6895ec48c16mr10101637b3.2.1723067245232; Wed, 07 Aug 2024 14:47:25 -0700 (PDT) Date: Wed, 7 Aug 2024 14:47:24 -0700 (PDT) From: Cory Fields To: Bitcoin Development Mailing List Message-Id: <6cfd5a56-84b4-4cbc-a211-dd34b8942f77n@googlegroups.com> Subject: [bitcoindev] Bitcoin Core's migration to the CMake buildsystem MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4892_713725626.1723067244963" X-Original-Sender: foss@coryfields.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_4892_713725626.1723067244963 Content-Type: multipart/alternative; boundary="----=_Part_4893_1225101412.1723067244963" ------=_Part_4893_1225101412.1723067244963 Content-Type: text/plain; charset="UTF-8" Hi All I realize this is not a Bitcoin Core list, but I think this is relevant enough to many downstream developers to bring up here. Hennadii Stepanov (hebasto) has been working hard for several years now to replace Bitcoin Core's Autotools-based buildsystem with a modern CMake one. Most of the developers who support the current buildsystem have been reviewing this work chunk-by-chunk in hebasto's staging branch since February of last year. As I've been helping with guidance and review of this work, hebasto has asked me to share a quick summary of our progress. Anyone who's ever been around for a buildsystem migration in a large software project knows what a massive undertaking this is, as well as the frustrations that come along with it. This one is no exception. So before going further, I'd like to commend hebasto on his hard work and patience to get this far. Thanks, hebasto! In the process, we've upstreamed dozens of bugfixes and modernizations for our various build-time and run-time dependencies. Thanks especially to Michael Ford (fanquake) for that effort. In the true open-source spirit, other users of those dependencies have received some free improvements from this work. Now that it's gone through a long round of review by the buildsystem devs, we believe it's in good enough shape to merge into master in the upcoming weeks as planned, soon after feature-freeze for v28 and branch-off for v29. We recognize that this will be a bumpy time for Bitcoin Core dev. It's simply impossible to avoid problems with a change like this. We believe that common workflows should be mostly uninterrupted, but those of you targeting esoteric platforms or build configs are more likely to run into some issues. So this would be a good time (before merge!) for anyone who builds Bitcoin Core to give the CMake branch a try and let us know about any trouble you've run into. Please re-read that last paragraph. This _will_ be a painful process. Please try to be constructive/productive with your bug reports. The current PR can be found here: https://github.com/bitcoin/bitcoin/pull/30454 The build-related documentation has been updated there. Please consider that documentation to be canonical, so if there's a question that's not answered (or info that's stale), please mention it in the form of a review on the pull request so that everyone can benefit. FAQ: Q: Noooooooooo!!! A: That's not a question :). Maintaining Autotools is a huge burden and it's only getting worse over time as it's virtually (though not entirely) unmaintained. As the person who introduced and maintained the current buildsystem and maintained it for years (though others like fanquake and hebasto have been more active for the last few) I'm happy to see it go. She sure was a good ship. Q: Why CMake? Why not [my favorite buildsystem] A: Because CMake is a perfectly reasonable choice for a modern free and open-source buildsystem with substantial momentum. And also because hebasto stepped up to actually do the work. Q: Will Autotools continue to be supported? A: Not in master, no. We (the buildsystem devs) don't believe it's worth the pain/effort of maintaining parallel buildsystems for a project as large as Bitcoin Core. We plan to delete everything relating to Autotools within days of merging CMake. However, we have no intention of backporting CMake to previous branches, so we'll have to maintain it to a small degree there. Q: When/how will this affect me as a user of Bitcoin Core. A: If don't build Bitcoin Core from source, or if you don't know what that means, you shouldn't notice any change. Q: When/how will this affect me as a developer who interacts with Bitcoin Core? A: For builders of Core who are not Core devs, You'll probably encounter a new way of building Core when v29 is released, sometime mid next year. At that point, rather than "./configure && make", you'll be using "cmake -S . -B build && cmake --build build". With any luck, by then, most of the bugs will have been reported and fixed, and builds will just work. Q: When/how will this affect me as a Core-dev? A: Today! Now! Please try out #30454 and report any issues there. Please try to avoid bikeshedding as much as possible though. Q: How do I configure the build? Where are the old options? A: All relevant options have been ported over. See the docs for more details, but as a hint, the ccmake tool is very useful for listing build options. Additionally, hebasto has been keeping up with a feature-parity table here: https://gist.github.com/hebasto/2ef97d3a726bfce08ded9df07f7dab5e Q: Why is X tool or Y feature off by default? A: We've decided to stick to the CMake way of doing things as much as possible. This way, a quick web search for "how to do Z with CMake" will probably turn up helpful and correct answers. Although, this paradigm switch is where we anticipate the most friction and frustration for users during the transition. While Autotools convention is to automatically find and enable features when possible (like enabling a feature if a library happens to exist on your system), the common CMake way is to require explicit opt-ins. This leads to fewer surprises as there's less magic happening out of sight, but may require a small upfront time investment to get back to the builds you're used to. Q: Are all of CMake's cool features supported? A: Some, not all. Focus has been on getting the initial port done correctly, with less effort going to fringe features and non-makefile generators. Generally speaking, single-config Makefiles have received the most attention. Ninja should just work. Multi-config builds may work, but we don't guarantee/support that just yet. MSVC should be in good shape as that's hebasto's platform of choice. XCode is known to work, but it's currently not very usable as it's unorganized and the build is full of irrelevant warnings. We'll clean those up in due time, but they're not high priority as we consider them new features as opposed to part of the initial port. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6cfd5a56-84b4-4cbc-a211-dd34b8942f77n%40googlegroups.com. ------=_Part_4893_1225101412.1723067244963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All

I realize this is not a Bitcoin Core list, but I think th= is is relevant enough to many downstream developers to bring up here.
=
Hennadii Stepanov (hebasto) has been working hard for several years n= ow to replace Bitcoin Core's Autotools-based buildsystem with a modern CMak= e one. Most of the developers who support the current buildsystem have been= reviewing this work chunk-by-chunk in hebasto's staging branch since Febru= ary of last year. As I've been helping with guidance and review of this wor= k, hebasto has asked me to share a quick summary of our progress.

Anyone who's ever been around for a buildsystem migration in a large soft= ware project knows what a massive undertaking this is, as well as the frust= rations that come along with it. This one is no exception. So before going = further, I'd like to commend hebasto on his hard work and patience to get t= his far. Thanks, hebasto!

In the process, we've upstreamed dozen= s of bugfixes and modernizations for our various build-time and run-time de= pendencies. Thanks especially to Michael Ford (fanquake) for that effort. I= n the true open-source spirit, other users of those dependencies have recei= ved some free improvements from this work.

Now that it's gone th= rough a long round of review by the buildsystem devs, we believe it's in go= od enough shape to merge into master in the upcoming weeks as planned, soon= after feature-freeze for v28 and branch-off for v29.

We recogni= ze that this will be a bumpy time for Bitcoin Core dev. It's simply impossi= ble to avoid problems with a change like this. We believe that common workf= lows should be mostly uninterrupted, but those of you targeting esoteric pl= atforms or build configs are more likely to run into some issues. So this w= ould be a good time (before merge!) for anyone who builds Bitcoin Core to g= ive the CMake branch a try and let us know about any trouble you've run int= o.

Please re-read that last paragraph. This _will_ be a painful = process. Please try to be constructive/productive with your bug reports.
The current PR can be found here: https://github.com/bitcoin/bitco= in/pull/30454

The build-related documentation has been updated t= here. Please consider that documentation to be canonical, so if there's a q= uestion that's not answered (or info that's stale), please mention it in th= e form of a review on the pull request so that everyone can benefit.
<= br />FAQ:

Q: Noooooooooo!!!
A: That's not a question :). Ma= intaining Autotools is a huge burden and it's only getting worse over time = as it's virtually (though not entirely) unmaintained. As the person who int= roduced and maintained the current buildsystem and maintained it for years = (though others like fanquake and hebasto have been more active for the last= few) I'm happy to see it go. She sure was a good ship.

Q: Why C= Make? Why not [my favorite buildsystem]
A: Because CMake is a perfectl= y reasonable choice for a modern free and open-source buildsystem with subs= tantial momentum. And also because hebasto stepped up to actually do the wo= rk.

Q: Will Autotools continue to be supported?
A: Not in m= aster, no. We (the buildsystem devs) don't believe it's worth the pain/effo= rt of maintaining parallel buildsystems for a project as large as Bitcoin C= ore. We plan to delete everything relating to Autotools within days of merg= ing CMake. However, we have no intention of backporting CMake to previous b= ranches, so we'll have to maintain it to a small degree there.

Q= : When/how will this affect me as a user of Bitcoin Core.
A: If don't = build Bitcoin Core from source, or if you don't know what that means, you s= houldn't notice any change.

Q: When/how will this affect me as a= developer who interacts with Bitcoin Core?
A: For builders of Core wh= o are not Core devs, You'll probably encounter a new way of building Core w= hen v29 is released, sometime mid next year. At that point, rather than "./= configure && make", you'll be using "cmake -S . -B build &&= cmake --build build". With any luck, by then, most of the bugs will have b= een reported and fixed, and builds will just work.

Q: When/how will this affect me as a Core-dev?
A: Today! Now! = Please try out #30454 and report any issues there. Please try to avoid bike= shedding as much as possible though.

Q: How do = I configure the build? Where are the old options?
A: All relevant opti= ons have been ported over. See the docs for more details, but as a hint, th= e ccmake tool is very useful for listing build options.
Additionally, = hebasto has been keeping up with a feature-parity table here: https://gist.= github.com/hebasto/2ef97d3a726bfce08ded9df07f7dab5e

Q: Why is X = tool or Y feature off by default?
A: We've decided to stick to the CMa= ke way of doing things as much as possible. This way, a quick web search fo= r "how to do Z with CMake" will probably turn up helpful and correct answer= s. Although, this paradigm switch is where we anticipate the most friction = and frustration for users during the transition. While Autotools convention= is to automatically find and enable features when possible (like enabling = a feature if a library happens to exist on your system), the common CMake w= ay is to require explicit opt-ins. This leads to fewer surprises as there's= less magic happening out of sight, but may require a small upfront time in= vestment to get back to the builds you're used to.

Q: Are all of= CMake's cool features supported?
A: Some, not all. Focus has been on = getting the initial port done correctly, with less effort going to fringe f= eatures and non-makefile generators. Generally speaking, single-config Make= files have received the most attention. Ninja should just work. Multi-confi= g builds may work, but we don't guarantee/support that just yet. MSVC shoul= d be in good shape as that's hebasto's platform of choice. XCode is known t= o work, but it's currently not very usable as it's unorganized and the buil= d is full of irrelevant warnings. We'll clean those up in due time, but the= y're not high priority as we consider them new features as opposed to part = of the initial port.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/6cfd5a56-84b4-4cbc-a211-dd34b8942f77n%40googlegroups.com.=
------=_Part_4893_1225101412.1723067244963-- ------=_Part_4892_713725626.1723067244963--