Looks like this is just adding a bunch of bloat that should later-on be removed anyway. How is a one-line include different/better than a simple one-line extern RecursiveMutex cs_main;?

How is a one-line include different/better than a simple one-line extern RecursiveMutex cs_main;?

It's probably neither much different or better, just one way of acheiving the same thing. The point is to remove unecessary/heavy includes, which aside from improving compilation time / # of units to rebuilt due to source changes, also enables cleanup like #26087. If we'd rather use extern RecursiveMutex cs_main; everywhere, and then drop unused validation includes when possible, that could also be fine, I'm not tied to a specific approach.

that should later-on be removed anyway.

If it's going to be removed later on, having a single file/include to delete is at least somewhat convenient. Although similarly so to removing a number of extern RecursiveMutex....

The point is to remove unecessary/heavy includes

I don't see how this pull achieves any of that or would help there. You are adding the cs_main.h include to 40 files, all of which either have validation already included or had their extern cs_main replaced.

How is a one-line include different/better than a simple one-line extern RecursiveMutex cs_main;?

It's probably neither much different or better, just one way of acheiving the same thing. The point is to remove unecessary/heavy includes, which aside from improving compilation time / # of units to rebuilt due to source changes

Agree with the goal of cleaning up includes, and also agree neither extern RecursiveMutex cs_main; nor #include <cs_main.h> seem much better or worse. Would probably favor the extern over the include for a smaller diff and a little less complexity, unless there are other reasons for wanting the include.

Concept ACK. For files that need it, I think it makes sense to be able to include just cs_main without having to know its signature or pull in a header that thinks it knows it.

And giving it a home in its own compilation unit means that we no longer have to pull in the arbitrary object where it resides just to get it linked. So I think this is a nice cleanup.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

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.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #26762 (refactor: Make CCheckQueue RAII-styled by hebasto)
• #26705 (clang-tidy: Check headers and fixes them by hebasto)
• #25862 (refactor, kernel: Remove gArgs accesses from dbwrapper and txdb by ryanofsky)
• #25781 (Remove almost all blockstorage globals by MarcoFalke)

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.

An #include seems preferable to redeclaring it directly; not really seeing the need to add the #include to cpp files that already #include <validation.h> though. Adding #include <cs_main.h> // IWYU pragma: export in validation.h should satisfy IWYU, I think?

IWYU can't even produce the correct includes for a single line of code like int main() {std::regex{std::string{}};}, let alone on our code base as a whole. So I don't think IWYU should be used as a reason for this change.

So I don't think IWYU should be used as a reason for this change.

I was assuming silencing IWYU complaints was the only reason for adding for adding cs_main.h where validation.h was already included.

@fanquake did you check if any #include <validation.h> could be removed?

EDIT: irrelevant after #26251 (comment)

ACK 282019c