💬 hebasto commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295181963)
> Shouldn't this PR also remove the build_msvc directory and related doc?

This is supposed to be done in a follow-up PR (see https://github.com/hebasto/bitcoin/pull/166 and https://github.com/bitcoin/bitcoin/pull/30664).

💬 hebasto commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295183828)
> I'm doing some test builds on Windows and it was a bit of a treasure hunt to find the binaries. The relevant doc states "CMake will put the resulting object files, libraries, and executables into a dedicated build directory.". Would it be worth listing the directories?
>
> The Autotools Linux based builds put the binaries into a single obvious location. If that's tricky with cmake then maybe the next best thing is to list the locations where the binaries can be found?

A solution similar
...

💬 sipsorcery commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1720944823)
It would be useful to know what the install command will do.

📝 paplorinc opened a pull request: "doc: Extend developer-notes with file-name-only debugging fix"
(https://github.com/bitcoin/bitcoin/pull/30670)
Split out of https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1714285678

While testing the new `cmake` build with [CLion](https://youtrack.jetbrains.com/issue/CPP-15850/Debugger-doesnt-stop-on-breakpoints-in-case-of-fdebug-prefix-map#focus=Comments-27-4926356.0-0), I noticed that the tests don't always stop at the set breakpoints, so I've updated the `developer-notes.md`, hoping it will be useful for others experiencing the same.

Added links to gdb and lldb documentations.

Ass
...

✅ paplorinc closed a pull request: "optimization: Optimize IsSpace function for common non-whitespace characters"
(https://github.com/bitcoin/bitcoin/pull/29602)

👋 paplorinc's pull request is ready for review: "test: Fuzz the human-readable part of bech32 as well"
(https://github.com/bitcoin/bitcoin/pull/30623)

⚠️ GregTonoski opened an issue: "bitcoind shouldn't be shutdown automatically despite wallet synchronisation error"
(https://github.com/bitcoin/bitcoin/issues/30671)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Bitcoind startup is terminated.

### Expected behaviour

bitcoind should complete startup and keep running successfully.

### Steps to reproduce

Step:
`$ ./bitcoind`

### Relevant log output

Result (logs):
Keys: 9 plaintext, 0 encrypted, 0 w/ metadata, 9 total. Unknown wallet records: 0
Wallet completed loading in 326ms
Error: Prune: last wallet synchronisation goes beyon
...

💬 sipsorcery commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1720958987)
Is this meant to be cmake not gmake?

🤔 fjahr reviewed a pull request: "validation: improve m_best_header tracking"
(https://github.com/bitcoin/bitcoin/pull/30666#pullrequestreview-2244288429)
tACK c9bf06a531617fdd70b64e23572931af2b969828

I reviewed the code and confirmed manually that all the added tests do test the behavior changes in their commits.

I would also say this is a bugfix, so the title could be changed to "Fix m_best_header tracking" and get a bugfix label.

💬 fjahr commented on pull request "validation: improve m_best_header tracking":
(https://github.com/bitcoin/bitcoin/pull/30666#discussion_r1720957497)
Could move this comment into `validation.h` and make it available for doxygen.

💬 fjahr commented on pull request "validation: improve m_best_header tracking":
(https://github.com/bitcoin/bitcoin/pull/30666#discussion_r1720960447)
nit: not sure if this needs to be check over the life time of the test. master only fails on the last added line so I feel this is a bit verbose and distracting from what this test is actually added for.

💬 hebasto commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1720978737)
It installs the built project to the default install prefix, which is the value of the `CMAKE_INSTALL_PREFIX` variable.

💬 fjahr commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#discussion_r1720984906)
> I think you can make a symlink in the repo and just make sure it's updated every time.

I tried this but it seems like it's not supported. I didn't an official statement but here is a discussion that seems to confirm there is not way to use symlinks for this: https://github.com/dear-github/dear-github/issues/156

💬 ryanofsky commented on pull request "refactor: Replace ParseHex with consteval HexLiteral":
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721008790)
re: https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1720801552

> I mean both `Vec(HexLiteral(` and the existing `ToByteVector(HexLiteral(` would work here, right?

Right, ToByteVector could be used here instead of Vec, and Vec was just chosen because it is shorter. Sorry I misunderstood your original question.

I do think in general Vec has some benefits over ToByteVector:

- `Vec` only changes the type of the container, not the type of the elements inside the container, so it
...

💬 ryanofsky commented on pull request "refactor: Replace ParseHex with consteval HexLiteral":
(https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1721004385)
re: https://github.com/bitcoin/bitcoin/pull/30377#discussion_r1720801377

Yes, you're right , I misread the suggestion. Using valtype to construct vectors would not change which CScript method is called, so it should be not a problem to make that change in this PR, and maybe it would be better. I do think tests would be more readable and consistent if they used HexLiteral as much as possible to represent raw bytes, but that's a subjective opinion and your approach seems fine too.

💬 johndpierre1 commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295339790)
Hey

On Sun, Aug 4, 2024 at 11:40 l0rinc ***@***.***> wrote:

> I can barely contain my excitement about this change, finally the whole
> project came alive for me in CLion - a few of the features that are working
> with cmake that didn't work before:
>
> - right click to run boost test + debug:
>
> image.png (view on web)
> <https://github.com/user-attachments/assets/ab8c93f8-58e0-435f-b834-51e245a26468> image.png
> (view on web)
> <https://github.com/user-attachments/assets/d20
...

⚠️ bitcoinchunk opened an issue: "Question on Changing Bitcoin Blockchain Data Directory in Linux Without Redownloading"
(https://github.com/bitcoin/bitcoin/issues/30672)
Hello Bitcoin Community,

I’m looking for some guidance on how to change the default data directory for the Bitcoin blockchain on a Linux system. I want to move the blockchain data to a different drive with more space, but I’d prefer not to download the entire blockchain from scratch.

Could someone walk me through the steps to move the data seamlessly, ensuring that all configurations are correctly updated? Any tips to avoid issues during the process would be greatly appreciated.

Thanks
...

💬 whitslack commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065)
> I'm doing some test builds on Windows and it was a bit of a treasure hunt to find the binaries.

@sipsorcery: Rather than going on a treasure hunt, wouldn't you "install" the built product to a staging directory and then produce your distributable package from there? That way you'll pick up all the bits that the build system wants you to have and none that it doesn't.

💬 whitslack commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367078)
> > One small gripe: When we enter the install phase, CMake always rebuilds `src/clientversion.cpp`, which forces a relink of all target executables. It would be better if `ninja install` would not rebuild anything.
>
> Is this still an issue with the recent update?

@hebasto: Nope! It works as expected at 41051290ab3b6c36312cec26a27f787cea9961b4. :grin: Thanks!

💬 johndpierre1 commented on pull request "build: Introduce CMake-based build system":
(https://github.com/bitcoin/bitcoin/pull/30454#issuecomment-2295367360)
Who is using my email to text you
I have been hacked


On Sun, Aug 18, 2024 at 20:30 Matt Whitlock ***@***.***>
wrote:

> ***@***.**** commented on this pull request.
> ------------------------------
>
> In doc/build-windows-msvc.md
> <https://github.com/bitcoin/bitcoin/pull/30454#discussion_r1721043065>:
>
> > +
> +### 4. Building with Dynamic Linking with GUI
> +
> +```
> +cmake -B build --preset vs2022 -DBUILD_GUI=ON # It might take a while if the vcpkg binary cache is unpop
...