For example the file $workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/frame/XFrame.hpp has an > #include "com/sun/star/frame/XFrame.hpp" Normally this is no issue because of the #ifndef include guards. But when you try to analyse the includes with iwyu (Bug 42949) it stops because of the cyclic include. > Cycle in include-mapping: > "com/sun/star/frame/XFrame.hpp" -> > "com/sun/star/frame/XFrame.hpp" > /build/iwyu-qvr6nD/iwyu-3.9/iwyu_include_picker.cc:844: Assertion failed: Cycle in include-mapping > Aborted (core dumped) According to codemaker README, cppumaker generates those .hpp files. Help from someone with knowledge of cppumaker code is very welcome.
But that's a bug in iwyu, no? We could drop those redundant includes, but then we'd still get cycles when e.g. has a method parameter of type XBar derived from XFoo. (And in .hpp files, Includes::dump in codemaker/source/cppumaker/includes.cxx always uses #include, never a forward decl, for reasons that escape me now. We could thus probably get rid of such cycles if we could use forward decls thereM but I'd rather prefer to get the issue solved in the tool that chokes?)
(In reply to Stephan Bergmann from comment #1) > But that's a bug in iwyu, no? > > We could drop those redundant includes, but then we'd still get cycles when > e.g. has a method parameter of type XBar derived from XFoo. (And in .hpp > files, Includes::dump in codemaker/source/cppumaker/includes.cxx always uses > #include, never a forward decl, for reasons that escape me now. We could > thus probably get rid of such cycles if we could use forward decls thereM > but I'd rather prefer to get the issue solved in the tool that chokes?) yes, it's a problem with iwyu. A relevant bug report seems to be: https://github.com/include-what-you-use/include-what-you-use/issues/424 There is not much progress on the issue, though. I trigger this problem only with self includes not by other cycles. At the moment I compile once, fix the self includes in most common hpp headers with a script (offapi and udkapi) and compile again. (Then I configure build to use iwyu, 'touch' the source files I want to target and run make.) It would already help to know all make targets for UNO api headers.
I think this was fixed recently in bug #117918 *** This bug has been marked as a duplicate of bug 117918 ***