Doxygen: new upstream feature adds Doxyfile.xml which breaks m.css XML consumption

[marzer]

As of doxygen/doxygen#8463 Doxygen spits out an XML rendition of the doxyfile contents as Doxyfile.xml, which m.css dutifully tries to consume as though it were a <compounddef> or similar.

I guess you could just skip/delete the Doxyfile.xml, though a more tool-friendly way around this would be to expose an --ignore option to do the inverse of what --wildcard does now, to allow tool devs to say "hey, ignore any xml files matching this pattern", and always add Doxyfile.xml to it implicitly.

(it occurs to me that you may also want to use the Doxyfile.xml to inform m.css behaviour; it seems a pretty useful feature and probably one Doxygen should have been doing a long time ago hah)

[mosra]

(Sorry for embarrassingly late replies, finally got back to this project and to the final boss that is Doxygen.)

This is now fixed with a variant of #207, commited as 45911a1.

it occurs to me that you may also want to use the Doxyfile.xml to inform m.css behaviour

Yes, in an ideal world, and if

probably one Doxygen should have been doing a long time ago hah

would hold true. But in reality, I have to parse Doxyfile first and only then execute Doxygen, because it's stupid:

m.css/documentation/doxygen.py

Lines 3886 to 3890 in 013b708

	# Doxygen is stupid and can't create nested directories, create the input
	# directory for it. Don't do it when the argument is empty, because
	# apparently makedirs() is also stupid.
	if state.doxyfile['OUTPUT_DIRECTORY']:
	os.makedirs(state.doxyfile['OUTPUT_DIRECTORY'], exist_ok=True)

Lalala 🎶

[marzer]

Thanks for addressing this :)

Sorry for embarrassingly late replies

Man, absolutely no worries. I know the feeling. Projects don't just sneak away, they sprint away from us like they stole something.