path: root/45/26371f167fea9fe6a681f529d7ac400cb35906

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 <bitcoindev+bncBDM7J3EO6EORBOOZZ62QMGQE35IQIOI@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <foss@coryfields.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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<br /><br />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.<br />=
<br />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.<br /><br =
/>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!<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Please re-read that last paragraph. This _will_ be a painful =
process. Please try to be constructive/productive with your bug reports.<br=
 /><br />The current PR can be found here: https://github.com/bitcoin/bitco=
in/pull/30454<br /><br />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 /><=
br />FAQ:<br /><br />Q: Noooooooooo!!!<br />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.<br /><br />Q: Why C=
Make? Why not [my favorite buildsystem]<br />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.<br /><br />Q: Will Autotools continue to be supported?<br />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.<br /><br />Q=
: When/how will this affect me as a user of Bitcoin Core.<br />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.<br /><br />Q: When/how will this affect me as a=
 developer who interacts with Bitcoin Core?<br />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 &amp;&amp; make", you'll be using "cmake -S . -B build &amp;&amp;=
 cmake --build build". With any luck, by then, most of the bugs will have b=
een reported and fixed, and builds will just work.<br /><div><br /></div><d=
iv>Q: When/how will this affect me as a Core-dev?</div><div>A: Today! Now! =
Please try out #30454 and report any issues there. Please try to avoid bike=
shedding as much as possible though.<br /></div><div><br /></div>Q: How do =
I configure the build? Where are the old options?<br />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.<br />Additionally, =
hebasto has been keeping up with a feature-parity table here: https://gist.=
github.com/hebasto/2ef97d3a726bfce08ded9df07f7dab5e<br /><br />Q: Why is X =
tool or Y feature off by default?<br />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.<br /><br />Q: Are all of=
 CMake's cool features supported?<br />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.

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/6cfd5a56-84b4-4cbc-a211-dd34b8942f77n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/6cfd5a56-84b4-4cbc-a211-dd34b8942f77n%40googlegroups.com</a>.=
<br />

------=_Part_4893_1225101412.1723067244963--

------=_Part_4892_713725626.1723067244963--