jenkins test make check

jenkins test make check arm64

jenkins test windows

jenkins test api

This PR is broken because it depends on include corrections in other subsystems. I'll need to split other commits from the big draft PR first.

I have rebased this PR on #61607 plus two more bug fix patches. With these, I can build Ceph locally; let's see if the CI is happy.

The two CI failures (SIGBUS, SIGSEGV) look unrelated to these compile-time changes.

Is it intended that commits touching the RBD CLI tool, rbd-mirror daemon and rbd-nbd driver ended up in the PR for the "mon" subsystem?

Not quite, but my first attempt at this PR caused build failures in these other subsystem because includes there were missing. So I added more commits to check what the minimum set of fixes is needed to fix this PR. (Ceph is a fragile mess!)

btw. @idryomov check my comment here: #61607 (comment)

caused build failures in these other subsystem because includes there were missing ... (Ceph is a fragile mess!)

(You may have elaborated on this in one of the other PRs that clean up includes, if so feel free to just post a link.)

I'm curious how you are building Ceph that you are hitting these build issues so reliably? Between the full-time developers and Jenkins, either various subsets or the entire project gets built well over a hundred times a day and all those builds pass (at least to the best of my knowledge). Are you doing it with no concurrency to fit into a small RAM budget or some kind of piece-wise builds juggling individual make/ninja targets?

btw. @idryomov check my comment here: #61607 (comment)

Is this in relation to RBD? That comment seems orthogonal to the thread here.

Is this in relation to RBD? That comment seems orthogonal to the thread here.

Not RBD, but MGR. The MGR commits in this PR are "borrowed" from the other PR, and the comment I linked to explains that this PR depends on the other PR or else Ceph fails to build.

I'm curious how you are building Ceph that you are hitting these build issues so reliably?

Most of the build failures happen when I remove unnecessary includes from headers, but then dozes of other sources fail to compile because they depend on a certain header without including it. Prior to my work, that just happened to work by chance, not by design, due to the many (unnecessary) indirect includes. So a good piece of my work is to add all the include directives that are missing.

But there were also many Ceph build failures without any of my include cleanups. I tried to build just MDS (because MDS is all I'm interested in right now), so I disabled all the features that are not relevant for MDS (e.g. Bluestore) to speed up the build (Ceph build times are very painful). Just look at all my Bluestore-related PRs, e.g. #61019 #60547 #60305 #61020
These never occurred to all of you because apparently nobody (except me) has ever built Ceph without Bluestore support.

I tried to build just MDS (because MDS is all I'm interested in right now), so I disabled all the features that are not relevant for MDS (e.g. Bluestore) to speed up the build (Ceph build times are very painful). Just look at all my Bluestore-related PRs, e.g. #61019 #60547 #60305 #61020
These never occurred to all of you because apparently nobody (except me) has ever built Ceph without Bluestore support.

Right -- building Ceph without Bluestore is weird because once you build your changes you generally want to test them end-to-end and if it's not a trivial test where a RAM-backed object store can do, Bluestore is very much needed ;) People absolutely (re)build just the MDS all the time, but only after having built "the world" once.

People absolutely (re)build just the MDS all the time, but only after having built "the world" once.

I don't want do build the world, only MDS. I have a draft patch that allows enabling/disabling all of those top-level components, and if you enable only MDS, then cmake will only look for the dependencies needed by MDS. I might some day finish it and submit it.
Right now, I can build just MDS, but I still need all the dependencies for all other compoenents, and that annoys me.

@MaxKellermann I merged #61607, this PR can be rebased.

jenkins test api

What's with these qatzip errors?

./qatzip_internal.h:445:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
void streamBufferCleanup();
                        ^
                         void
1 error generated.
make[1]: *** [Makefile:528: libqatzip_la-qatzip_counter.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
In file included from qatzip.c:67:
./qatzip_internal.h:445:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
void streamBufferCleanup();
                        ^
                         void
In file included from qatzip_gzip.c:51:
./qatzip_internal.h:445:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
void streamBufferCleanup();
                        ^
                         void
1 error generated.
make[1]: *** [Makefile:535: libqatzip_la-qatzip_gzip.lo] Error 1
qatzip.c:1680:18: error: variable 'sleep_cnt' set but not used [-Werror,-Wunused-but-set-variable]
    unsigned int sleep_cnt = 0;
                 ^
qatzip.c:2565:18: error: variable 'sleep_cnt' set but not used [-Werror,-Wunused-but-set-variable]
    unsigned int sleep_cnt = 0;
                 ^

qatzip is a submodule, but how can this PR affect mistakes in the submodule?

qatzip is a submodule, but how can this PR affect mistakes in the submodule?

It's not caused by this PR, this is affecting other outstanding PRs as well.

jenkins test make check

jenkins test api

jenkins test make check

jenkins test api

jenkins test make check

the build failure should be fixed by #61827

The offending Jenkins builder is getting reimaged.

jenkins test make check