Add 'extern' to xml output

[michaeljones]

Attempts to resolve: #10163

Following the strategy taken in the sqlite output (#8533), we add extern if it is set regardless of whether it is a function, variable, etc.

It might be reasonable to only do it for functions and variables though. I don't know what the standard approach for these things is in the code base.

We have to update addGlobalFunction so that it passes on the explicitExternal information from Entry to the MemberDef which previously was only done for variables and enums.

Also:

• Update the xsd file to indicate that an optional extern attribute might be present on the members.

[albert-github]

Note that due to the change in compound.xsd also with doxmlparser some changes are required, though these changes require the installation of the generateDS package (to get the correct results).

[michaeljones]

Thanks for pointing that out. Unfortunately if I run:

python3 -m venv venv
source ./venv/bin/activate
pip install generateDS
mkdir build
cd build
cmake -Dbuild_xmlparser=YES ..
make

Then it ends up making significant changes to the compound.py and some changes to the index.py files. Do I need a specific version of generateDS to work properly? I can't see it in the requirements file.

I can commit all the changes and push them here if that would be useful. I can always roll them back. It does things like change def hasContent_ to def has__content which indicates I'm using an incorrect version, I guess.

[michaeljones]

Also CI seems to be failing on some Qt issues. I can't immediately see how they would be related to my changes. Are there just issues with CI at the moment?

[albert-github]

• generatDS tha I use is:

  generateDS.py version 2.37.15
  

  I do see often quite a few changes as well
• CI I had recently quite a few problems as we with the Qt installation as well ( I don't think they are on our side).

[michaeljones]

Ace, installing that version seems to have generated a much better diff. I've pushed that.

Do you think it might be reasonable to add the version to the requirements.txt in the doxmlparser folder? I'm not sure what that file is used for but it seems relevant and having the exact version would probably be useful for others.

[albert-github]

Thanks for the update.

I don't have any idea either where the requirement.txt is used, maybe it is a reminder for some versions to be used in generateDS or a Python way of chaecking, seen this it might be better to mention the version in the README.md of doxmlparser (or in the CMake i.e. check in the CMakeLists.txt)
I see that I have a fixed version of generateDS lying around so that the version is not "accidentally" updated .

[michaeljones]

I've added it to the README. I'm not familiar with CMake so I'm not well placed to make changes. That said, the cmake uses the --no-versions flag when invoking generateDS.py. It is possible that without that we'd get the version of generateDS in the auto generated code. That said, the flag has 'versions' plural so maybe we get the current python version and other things that are less desirable. Not sure. Happy to explore if you like or leave it as it is with the mention in the README.

[albert-github]

• as far as I can tell / remember the --no-versions has nothing to do with CMake but just with the mentioning of version of generateDS to generate the compound.py / index.py. The version of generateDS is not mentioned as different users might slightly different versions and this would be reflected in the output files as well (not nice in the repository and giving potentially a lot of unnecessary changes). We also use the script generateDS_post.py to filter more unwanted lines from the result (a u from the old Python 2 version that is not present in the Python 3 version).

I think mentioning the generateDS version in the README.md file is sufficient (and there are not a lot of people using generateDS for doxygen, as far as I can remember/know you are the first besides @doxygen and me).

[michaeljones]

Ok, cool. If you're happy then I'm happy. Let me know if there is anything else I can do on this PR, otherwise I'll leave it to you and @doxygen to merge as you see fit.

Edit: As the current CI failures appear to be unrelated to this change.