[POC] [RFC] build: Separate GUI application build system

hebasto commented at 7:06 pm on April 18, 2022: member

There is an inherent contradiction between (a) Bitcoin Core build system and (b) Bitcoin Core GUI build system.

Bitcoin Core:

strives to minimize dependencies for security reasons
adds new features without introducing new build dependencies (as usual)

Bitcoin Core GUI:

new features (e.g., QR-code reader, QML-based UI, OpenGL support, Wayland support) usually do introduce new build dependencies

A concept of the separated GUI build system is here: https://github.com/hebasto/bitcoin-qtw/commits/220418-add-core-subtree

One could test it as follows:

0$ ./autogen.sh
1$ ./configure --disable-fuzz-binary --disable-tests --disable-bench --without-utils --without-daemon --without-libs
2$ make
3$ ./src/qt/bitcoin-qt

The suggested approach uses this repository as a subtree.

Pros:

ability to drop GUI-related stuff from this repo
ability to use alternative build system for the current Qt Widget based GUI (e.g., use CMake which allows to adopt Qt6 more seamless, even without upstream support of *.pc files)
ability to develop alternative UI frameworks (e.g., Qt Quick based GUI; fwiw, keeping QML GUI project synchronized to this repo preserving commit history goes out of hands due to the shared build system)

Cons:

a GUI repo becomes a completely separated one, not like current https://github.com/bitcoin-core/gui
the release process requires to be modified to handle GUI binaries from a separated repo

hebasto added the label Brainstorming on Apr 18, 2022

hebasto added the label GUI on Apr 18, 2022

hebasto added the label Build system on Apr 18, 2022

JeremyRubin commented at 7:12 pm on April 18, 2022: contributor

concept ack

jarolrod commented at 6:26 am on April 19, 2022: member

This is less of “separate GUI application build system” and more of “seperate the gui into a new source tree”

Nevertheless, concept ack dependent on documented release process changes that keeps accessibility to the GUI as it is now (especially when grabbing the dmg or exe from bitcoincore.org); a part of bitcoin core.

otherwise, concept nack. bitcoin core packages together a coherent package of tools one needs to participate as a node in the network as well as ‘store’ bitcoin. The GUI plays a big role in both, especially with non-devs.

See: #19071

When a user downloads Bitcoin Core from our website (or another package manager) they expect the GUI to be included. This should not change (at least not as a result of splitting up the GUI into another project).

Similarly, when building Bitcoin Core, the gui should still be built when –with-gui is specified.

Making a note of the IRC discussion that accompanied moving the gui into a monotree repo: https://www.erisian.com.au/bitcoin-core-dev/log-2020-05-28.html#l-406

The discussion includes little nuggets like this:

2020-05-28T19:47:22 MarcoFalke: the gui made me contribute to Core

bitcoin deleted a comment on Apr 19, 2022

w0xlt commented at 7:00 am on April 20, 2022: contributor

Concept ACK. I think it makes the concepts more organized. The bitcoin/bitcoin project does the same with bitcoin-core/secp256k1.

sipa commented at 2:37 pm on April 20, 2022: member

It sounds like this issue isn’t about having a separate GUI build system, but a separate GUI repository? We could change the build system of the GUI even in the same repository; if that were what we really wanted, I think that’d even be easier than doing it in separate repositories.

Regarding the separation of repositories, I believe that is only a good idea if there is a well-defined stable interface between the codebases. Otherwise, you run into difficulties whenever changes to the boundary between the two need to be made, like lockstep commits and the synchronization overhead between the two projects - exactly what separating them likely was intended to avoid. I don’t know to what extent that is the case with the GUI at this point.

ryanofsky commented at 3:11 pm on April 20, 2022: contributor

I can’t figure out what is being proposed. What are the steps that will be taken? Description seems vague and https://github.com/hebasto/bitcoin-qtw/commits/220418-add-core-subtree just seems to show file renames

hebasto commented at 3:15 pm on April 20, 2022: member

I can’t figure out what is being proposed. What are the steps that will be taken? Description seems vague and https://github.com/hebasto/bitcoin-qtw/commits/220418-add-core-subtree just seems to show file renames

Split qt subdir into its own repo – https://github.com/hebasto/bitcoin-qtw/wiki/1.-Splitting-the-'qt'-subfolder-out-from-the-Bitcoin-Core-repository
In a new repo use this one, i.e., bitcon/bitcoin as a subtree.

After that any modifications in the new repo build system will not affect this repo build system, and vice verse.

maflcko commented at 3:20 pm on April 20, 2022: member

I agree with sipa that a separate GUI build system is large a separate issue from a separate GUI repo.

Instead of proposing both, it might be better to start with listing problems and goals, and then pick the solution that fits best.

hebasto commented at 3:28 pm on April 20, 2022: member

it might be better to start with listing problems and goals, and then pick the solution that fits best.

Repeating myself:

Bitcoin Core:

strives to minimize dependencies for security reasons

adds new features without introducing new build dependencies (as usual)

Bitcoin Core GUI:

new features (e.g., QR-code reader, QML-based UI, OpenGL support, Wayland support) usually do introduce new build dependencies

The main problem – What is a widely accepted by developers in this repo way to introduce new GUI-specific features which usually require new build dependencies?

ryanofsky commented at 3:31 pm on April 20, 2022: contributor

Thanks for the more detailed description! (https://github.com/bitcoin/bitcoin/issues/24911#issuecomment-1104053117).

Concept ~0 for me, since I don’t work very heavily with the build system, and I think people who do work more on build issues are in a better position to decide what their preferences are.

I do now understand why this issue is proposing separating the build system and repositories both at the same time. With the changes you described to the build system which make make bitcoin-qt build depend on the bitcoind build, it would make no sense to keep dead bitcoin-qt stuff inside the bitcoind repository.

maflcko commented at 3:49 pm on April 20, 2022: member

It looks like this thread might be a response to #22708 (comment) ?

If yes, I don’t think introducing a new build system or moving stuff from this repo into another repo is a solution. After all we still need to have the code in this repo to run the guix build and produce the gui binaries, so it seems easiest to put whatever needs to be done inside this repo.

I think the design goals of Bitcoin Core should also (on a best effort basis) be applied to the GUI. So if you want to introduce a new GUI feature and it seems useful, it should be added here. If it doesn’t seem useful, it probably shouldn’t be added, neither here or in a separate repo or separate build system.

hebasto commented at 3:55 pm on April 20, 2022: member

It looks like this thread might be a response to #22708 (comment) ?

Yes, but partially. Another issue comes from the QML project where keeping it synced and preserving this repo commit history goes really out of hands.

maflcko commented at 4:01 pm on April 20, 2022: member

If making this repo a subtree in the QML repo helps with development, then I think it can be done.

However, if the QML is eventually shipped to users, I don’t see a way around adding it to this repo.

fanquake commented at 11:19 am on August 12, 2022: member

The main problem – What is a widely accepted by developers in this repo way to introduce new GUI-specific features which usually require new build dependencies? There is an inherent contradiction between (a) Bitcoin Core build system and (b) Bitcoin Core GUI build system.

I don’t think there is a widely accepted way, because adding new features to the GUI is a rarity, and, as you’ve outlined in the op, what you want to do is at odds with our thesis of minimizing dependencies/third party code, and ultimately, the number of (unrelated to bitcoin) concerns we have to deal with in this repository.

As I outlined in this comment, #22708 (comment), without any coherent GUI plan, I’m not sure what to do. However I’m pretty certain the answer isn’t to keep adding new dependencies and support for more features (to the GUI).

I agree with Marcos comments here: #24911 (comment), shifting things to a new repo doesn’t really solve anything as long as this project is still building and releasing these binaries to end users.

fanquake commented at 11:05 am on February 24, 2023: member

Closing for now, as I don’t think there is anything actionable here. We aren’t going to add new dependencies any time soon, if ever, and we aren’t going to shuffle code/directories around (the linked branch) in this repository to facilitate easier rebasing in an experimental gui-fork.

fanquake closed this on Feb 24, 2023

bitcoin locked this on Feb 24, 2024

[POC] [RFC] build: Separate GUI application build system #24911