On Tue, Jun 25, 2024 at 10:23:54AM +0100, Peter Maydell wrote: > On Tue, 25 Jun 2024 at 03:20, Philippe Mathieu-Daudé <phi...@linaro.org> > wrote: > > Since you are posting different C++ enablement cleanups, > > I suggest you add a section in our docs/devel/style.rst > > requesting to keep headers C++ compatible, by not using > > C++ reserved keywords, etc... > > > > In particular because the mainstream project is not build-testing > > for C++, thus we will likely merge patches breaking C++ and > > make your life harder. That said, a C++ header smoke-build job > > in our CI could help. > > Unless there's some easy mechanism for contributors to check > that they haven't broken whatever our C++ requirement is, > I don't think we should define it in the style guide. > > More generally, we specifically removed the handling we > had for being able to include our headers from C++ source > files. (cf the stuff we added in commit 875df03b221 for > extern "C" blocks and then removed again later). If we're > not bringing that back (and I don't think we should) then > we're not actually trying to have our headers be C++ > compatible, so what are we aiming for?
I really dislike the drip-feeding of patches fixing C++ related problems. As maintainers we've no idea what the end state is, is this the last patch, or are there another 100 of these patches to trickle out one at a time. Ultimately from the QEMU maintainer POV anything related to C++ compatibility is a distraction, given the general consensus has turned to Rust as the future for QEMU, not C++. If we're going to take any C++ compat cleanups as a courtesy to ease burden of a downstream fork, then I'd like to see a complete series in one go, so we can sensibly evaluate whether the end state is something desirable from QEMU's POV. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
