This PR deletes the Autotools-based build system.
The MSVC build system is deleted in #30731.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
CreateTransaction
by brunoerg)MAC_OSX
macro with existing __APPLE__
by l0rinc)If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
🚧 At least one of the CI tasks failed. Debug: https://github.com/bitcoin/bitcoin/runs/28830258425
Make sure to run all tests locally, according to the documentation.
The failure may happen due to a number of reasons, for example:
Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.
Leave a comment here, if you need help tracking down a confusing failure.
Concept ACK on dropping Autotools quickly after merging cmake. Maintaining both sounds like a nightmare. Mainly for build system folks, but it’s also more work for people making pull requests that add/remove files. Best just get it over with.
I tested rebasing my Stratum v2 related pull requests (#29346, #30315, #29432 and several on my own fork). It was pretty straight-forward, see https://github.com/Sjors/bitcoin/pull/58.
I haven’t tried rebasing the IPC (multiprocess) variant of my PR. Testing @ryanofsky’s #30437 on top of this PR should probably reveal any relevant issues.
374- zmq/zmqutil.h
375-
376-
377-obj/build.h: FORCE
378- @$(MKDIR_P) $(builddir)/obj
379- $(AM_V_GEN) $(top_srcdir)/share/genbuild.sh "$(abs_top_builddir)/src/obj/build.h" \
style nit: If you are removing the only invocation of this script, wouldn’t it be better to remove the other mentions in the docs as well?
0cmake/script/GenerateBuildInfo.cmake:# This script is a multiplatform port of the share/genbuild.sh shell script.
1
2src/clientversion.cpp:// The <obj/build.h>, which is generated by the build environment (share/genbuild.sh),
Same for all other stuff that is no longer needed, like bear:
0ci/test/03_test_script.sh: # accepted in src/.bear-tidy-config
1doc/developer-notes.md:make clean && bear --config src/.bear-tidy-config -- make -j $(nproc)
…
bear
part was partly fixed in master.
style nit: If you are removing the only invocation of this script, wouldn’t it be better to remove the other mentions in the docs as well?
0cmake/script/GenerateBuildInfo.cmake:# This script is a multiplatform port of the share/genbuild.sh shell script. 1 2src/clientversion.cpp:// The <obj/build.h>, which is generated by the build environment (share/genbuild.sh),
Thanks! Removed.
share/
on purpose?
It aims reveal conflicts with other PRs.
For more details, please refer to today’s IRC meeting discussion.
It would be good to mention any important key points inline, otherwise it will be harder to understand whether this is the pull request that will be merged as a follow-up, and whether it should be reviewed, or if there is another place where the review should happen.
It aims reveal conflicts with other PRs. For more details, please refer to today’s IRC meeting discussion.
It would be good to mention any important key points inline, otherwise it will be harder to understand whether this is the pull request that will be merged as a follow-up, and whether it should be reviewed, or if there is another place where the review should happen.
The PR description has been updated with mentioning that this PR is not intended to be reviewed/merged in its current state. The branch will be updated once #30454 is merged.
At this moment, it is only about potential conflicts with other PRs.
I think this should properly remove all no-longer needed stuff.
Also, I think this should wait a few days, to allow everyone some time to upgrade and test parity, etc. See #30454 (comment)
temporary Approach NACK for that reason, from me at least
ACK debeb98fe3822962768127e5b5d312926f123211
I already reviewed this at https://github.com/hebasto/bitcoin/pull/166. Only minor changes since that + doc adjustment.
Eh?
Maintainers are free to ignore a review, but as per my previous comment, I think rushing this in without further and proper review will just lead to more follow-up pulls dealing with the stuff that was forgotten to be removed. Also, it is going to make parity testing harder while doing cmake follow-ups.
I just don’t see why this needs to be rushed, when there is no downside or even risk in waiting a few days at a minimum.
If I am missing a downside, it would be good to mention it.
In any case, it would be good to clarify whether review comments such as #30664 (comment) are expected to be addressed in this pull or in follow-ups. Otherwise, it is just unclear how reviewers should review this pull request.
All comments have been addressed unless I’ve overlooked something.
161@@ -162,8 +162,6 @@ if [ "${RUN_TIDY}" = "true" ]; then
162 echo "^^^ ⚠️ Failure generated from clang-tidy"
163 false
164 fi
165- # Filter out files by regex here, because regex may not be
166- # accepted in src/.bear-tidy-config
bear
? It’d be good to clarify if it is, or at the same time this comment is dropped, the redundant code should also be dropped?
EXPORT_COMPILE_COMMANDS
property is set to OFF
.
Yes, the filtering is still needed. If the filtering is moved to the cmake side, I’d say a follow-up would be better.
I’ve just finished my tests. Apparently, filtering is no longer required. I’ll submit a PR shortly and we can observe the IWYU output.
UPD. By “is no longer required”, I mean there are no IWYU violations in those files.
Ok, so I guess this comment should instead be changed to mention that it is still required by CMake. (Otherwise there is no context for why the filtering is happening or needed).
The comment has been adjusted.
Could rebase once more to make review easier?
Rebased.
There is a lot more docs to update still. After looking for a few seconds:
0.editorconfig:[configure.ac]
1src/util/fs_helpers.cpp:// for posix_fallocate, in configure.ac we check if it is present after this
2doc/developer-notes.md:Run configure with `--enable-debug` to add additional compiler flags that
3doc/developer-notes.md:configure option adds `-DDEBUG_LOCKORDER` to the compiler flags. This inserts
4doc/developer-notes.md:The `--enable-debug` configure option adds `-DDEBUG_LOCKCONTENTION` to the
5doc/developer-notes.md:configure with `-DDEBUG_LOCKCONTENTION` added to your CPPFLAGS,
6doc/developer-notes.md:`--with-sanitizers` configure flag, which should be a comma separated list of
7doc/developer-notes.md:./configure --with-sanitizers=address,undefined
8doc/developer-notes.md:./configure --with-sanitizers=thread
9doc/developer-notes.md:undefined sanitizer. If you are missing required libraries, the configure script
10doc/developer-notes.md:with `--with-sanitizers=address,thread` will fail in the configure script as
11doc/multiprocess.md:On unix systems, the `--enable-multiprocess` build option can be passed to `./configure` to build new `bitcoin-node`, `bitcoin-wallet`, and `bitcoin-gui` executables alongside existing `bitcoind` and `bitcoin-qt` executables.
12doc/multiprocess.md:CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure
13doc/multiprocess.md:The configure script will pick up settings and library locations from the depends directory, so there is no need to pass `--enable-multiprocess` as a separate flag when using the depends system (it's controlled by the `MULTIPROCESS=1` option).
14doc/multiprocess.md:Alternately, you can install [Cap'n Proto](https://capnproto.org/) and [libmultiprocess](https://github.com/chaincodelabs/libmultiprocess) packages on your system, and just run `./configure --enable-multiprocess` without using the depends system. The configure script will be able to locate the installed packages via [pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/). See [Installation](https://github.com/chaincodelabs/libmultiprocess/blob/master/doc/install.md) section of the libmultiprocess readme for install steps. See [build-unix.md](build-unix.md) and [build-osx.md](build-osx.md) for information about installing dependencies in general.
15doc/zmq.md: $ ./configure --disable-zmq (other options)
16share/qt/extract_strings_qt.py: print('Please install package "gettext" and re-run \'./configure\'.',file=sys.stderr)
17src/qt/README.md:2. Follow the compile instructions for your system, run `./configure` with the `--enable-debug` flag
18test/functional/test_runner.py: print("Rerun ./configure with --with-daemon and then make")
19test/get_previous_releases.py: './configure {}'.format(config_flags),
Again, it would be good to clarify whether reviewers should actually review this pull request or just blindly ACK it.
I am not really looking forward to 35 two-line doc fixup pulls over the next couple of months.
It would be good to complete the process fully and quickly with (let’s say) less than 3 pull requests.
… or just blindly ACK it.
No-one should blindly ACK.
134-linux-build
135-win32-build
136-test/config.ini
137-test/cache/*
138-test/.mypy_cache/
139-test/lint/test_runner/target/
8-arm*
9-aarch64*
10-powerpc*
11-riscv32*
12-riscv64*
13-s390x*
Ok, sounds like a plan! (No need to apologize) I can do the follow-up update also, but earliest in the second half of next week. The remaining missing removals/updates (on top of the one in my previous comment) would be:
0test/lint/lint-spelling.py:FILES_ARGS = ['git', 'ls-files', '--', ":(exclude)build-aux/m4/", ":(exclude)contrib/seeds/*.txt", ":(exclude)depends/", ":(exclude)doc/release-notes/", ":(exclude)src/qt/locale/", ":(exclude)src/qt/*.qrc", ":(exclude)contrib/guix/patches"]
1
2doc/build-unix.md:pass `--with-incompatible-bdb` to configure. Otherwise, you can build Berkeley DB [yourself](#berkeley-db).
Possibly drop libtool from:
0.github/workflows/ci.yml: brew install --quiet automake libtool pkg-config gnu-getopt ccache boost libevent miniupnpc libnatpmp zeromq qt@5 qrencode
1ci/test/00_setup_env.sh:export CI_BASE_PACKAGES=${CI_BASE_PACKAGES:-build-essential libtool autotools-dev automake pkg-config curl ca-certificates ccache python3 rsync git procps bison e2fsprogs cmake}
2ci/test/00_setup_env_i686_centos.sh:export CI_BASE_PACKAGES="gcc-c++ glibc-devel.x86_64 libstdc++-devel.x86_64 glibc-devel.i686 libstdc++-devel.i686 ccache libtool make git python3 python3-pip which patch lbzip2 xz procps-ng dash rsync coreutils bison util-linux e2fsprogs cmake"
3contrib/devtools/check-deps.sh:# Output makefile targets, converting library .a paths to libtool .la targets
4depends/README.md: apt install automake bison cmake curl libtool make patch pkg-config python3 xz-utils
5depends/packages.md:In general, the output of a depends package should not contain any libtool
6doc/build-unix.md: sudo dnf install gcc-c++ libtool make autoconf automake python3
review ACK 1954151c98c0ee4a9de3b10c450da235474d24a5 🎾
Signature:
0untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
1RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
2trusted comment: review ACK 1954151c98c0ee4a9de3b10c450da235474d24a5 🎾
3Kqi8XTd1pLYujuYSDQVRtxI8OH+AtHXDCqSbA+vpV79rlO/FYrHG3y5idrP0qDVFT/A38/VueOT8880DQXZLDQ==
85-*.raw.h
86-
87-# Only ignore unexpected patches
88-*.patch
89-!contrib/guix/patches/*.patch
90-!depends/patches/**/*.patch
67-.*.swp
68-*~
69-*.bak
70-*.rej
71-*.orig
72-*.pyc
Also not sure? If I do cmake -B build && cmake --build build -j12 && ctest --test-dir build
with this branch, now I have:
0# git status
1On branch 30664
2Untracked files:
3 (use "git add <file>..." to include in what will be committed)
4 share/rpcauth/__pycache__/
Which is share/rpcauth/__pycache__//rpcauth.cpython-312.pyc
.
Right. The master branch is not ready for that yet.
Fixed.
2@@ -3,154 +3,21 @@
3 !/build-aux
4 !/build_msvc
5
6-*.tar.gz
What do you suggest?
I’m still not sure how I feel about removing all of these. We are going to switch a lot between the versions with and without cmake over the next two years. Is it really desirable to have all these files appear in the untracked list?
From my personal experience during recent months, it isn’t a problem at all.
When I review a backport and come back again, this is how it looks like:
0> git status
1On branch master
2Untracked files:
3 (use "git add <file>..." to include in what will be committed)
4 Makefile
5 Makefile.in
6 aclocal.m4
7 autom4te.cache/
8... another 420 lines
This makes using git status
and a bunch of other git commands very annoying.
make clean && make distclean
before switching branches help? Alternatively, do out-of-tree autotools builds help to avoid the untracked files?
62-src/qt/bitcoin-qt.includes
63-
64-.deps
65-.dirstamp
66-.libs
67-.*.swp
65-.dirstamp
66-.libs
67-.*.swp
68-*~
69-*.bak
70-*.rej
Only change since last review is addressing feedback (removing a script and gitignore changes).
The gitignore still seem inconsistent, but I don’t care much either way personally.
re-ACK faa382ae7642da0e436ea2c7f7eac67386280a7e 🍦
Signature:
0untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
1RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
2trusted comment: re-ACK faa382ae7642da0e436ea2c7f7eac67386280a7e 🍦
3Pa+7MqVHY/VDhJZ9Bdbr49ElHmQ1m0FcmiE8YrnUkMTICFE3Iy6QvS8NHDfZWYXhVTSI8h8SiPcuVU/h+1urAQ==
144-/doc/doxygen/
145-
146-contrib/devtools/split-debug.sh
147-
148-# Output from running db4 installation
149-db4/
install_db4.sh
removal, but seems fine to do here.
ACK faa382ae7642da0e436ea2c7f7eac67386280a7e
The gitignore still seem inconsistent,
Especially given the comments in #30731 (review). Seems those should have been removed for the same reasoning as #30664 (review). Changes here seem completely arbitrary.
My latest review comments are on lines that are unrelated to switching branches. It is about temporary files in the source dir. Such files were created before cmake and will be created after cmake, because developers editing the source files will create them.
Personally I don’t use gitignore, so I don’t care, but it would be good to explain why the source-editing temporary-files changes are made and how they relate to autotools/cmake at all. Otherwise, there will be more follow-ups and confusion in the future.