References in a larger Project do not work anymore

[AlexWorx]

Summary

Several links in a bigger project do not work (giving the warning: unable to resolve reference), while they had worked in previous doxygen version.

Because the project is quite huge, I have let doxygen generate a tag-file and have included it in the ZIP.

Steps how I created the attached sample:

• First I ran doxygen on my own project (http://alib.dev) with

    GENERATE_TAGFILE       = ../html/cpp_ref.tag
  

• Then I copied the tag file to a new folder.

• There, I ran

    doxygen -g doxygen.ini
  

• Added one source to the ini file:

    INPUT                  = main.cpp
  

• Added tag import to the ini file:

    TAGFILES               =   cpp_ref.tag=https://alib.dev/
  

• Added file "main.cpp" to the folder

Steps to reproduce the bug:

• Run doxygen:

    doxygen doxygen.ini
  

• Open file

    html/classtest.html
  

  in a browser.

• You will see a few samples of links that can not be resolved.

Additional Notes:

• The problems did NOT occur with doxygen version 1.8.16.

• With new doxygen versions, I had always some new problems (while some old disappeared :-) and thus I was not able to update doxygen for a longer while.

• I had investigated quite a bit into the tag-file and think that everything is fine with it and the links should therfor work.

• Currently, I have set all these links "manually" in the actual live system, by retrieving the information from the tag-file, now as I finally switched to doxygen 1.10.

• Sorry for the inconvenience of providing such a large tag-file. But I do not know how I should otherwise cut this sample down. I know, with smaller projects, all seems fine. So I did not try to find a minimum sample.

doxygenALibRefTag.zip

[albert-github]

Then running the given project with the 1`.8.16 version I see (coloring the links red for better visibility):

with the 1.10.0 version I see:

• So it looks like I'm missing in the 1.8.16 version also some links

When looking in the tag file I see that:

• alib::expressions::Scope::Formatter isn't present

• alib::Bootstrap isn't present

• alib::loxLox::SetDomain isn't present

• lib::lang::system::Directory is present, but indeed the doxygen link jumps to the class instead of the constructor that is mentioned a bit further on in the tag file as:

    <member kind="function">
      <type></type>
      <name>Directory</name>
      <anchorfile>classalib_1_1lang_1_1system_1_1Directory.html</anchorfile>
      <anchor>a3d2aef8216e51d8fea90c4f4b4f26959</anchor>
      <arglist>(const String &amp;path)</arglist>
    </member>
  

• In the tag file I see that this one is from 1.11.0 (the master version) it would be good to have also the tag file generated with the 1.8.16 version.

As a side node it looks like the referenced web site is generated with the 1.10.0 version of doxygen.
Due to the usage of multiple versions here it is hard to tell what the problem is.

Is it correct that the sources are at https://github.com/AlexWorx/ALib-Class-Library and that the doxygen documentation could be created by running doxygen "using" the Doxyfile https://github.com/AlexWorx/ALib-Class-Library/blob/main/docs/doxygen/doxyfile.cmake.ini

[AlexWorx]

Summary

Thank you Albert for your fast pick-up of this issue! To your concrete comments:

• You can not compile the whole project with 1.8.16 anymore.
  This is mainly because I now use the custom separator feature with the Aliases.
  Almost all my links are set via doxygen aliases (macros, custom commands).

• You can also not use the current git-hub release of ALib to generate the dox.
  I update github only with releases, not with intermediate versions. And after switching to
  doxygen 1.10 I only updated the Homepage with the new doxygen output, not the github files.

• But I have included the current whole project for you (below)!

• My sample had one fault, it referenced
  alib::loxLox::SetDomain
  instead of
  alib::lox::Lox::SetDomain

• Otherwise, all other samples that you said are not to present in the tag file,
  are in fact are present (as far as I understand the tag file and as mentioned, with older
  doxygen versions it still worked)
  For your convenience, I have included the line numbers of the tag file in my new setup.

New setup, including the main project

I tried my best to keep it simple for you. Therefore, you'll find in the attached ZIP:

• Subfolder "ALib", which contains the current state of my C++ project which compiles well
  with the current master of doxygen (because I have manually set all links that doxygen does not find)
• Subfolder "SimpleTestWithTagImport", which is a slight modification of my first upload from
  yesterday.
• I have added the test case to both projects!
• I have adjusted the doxygen ini files so that, the tag file from the "ALib" project is directly
  written to the 2nd subfolder "SimpleTestWithTagImport" for it to use
• A simple shell script "makedox.sh" in the root folder, which has to be started
  from there as it uses relative paths.
  It compiles both projects.

Steps to reproduce the bug:

At first, you might not need to do anything, because all output (tagfile and 2 x html folders) is included in the ZIP.
I have compiled all with todays' doxygen master from github.
(The proof for this is that I could notice is that my other issue that you fixed yesterday into master is indeed fixed! ;-)

So, please:

• open "ALib/html/classdoxorigproject_1_1DoxygenErrors.html"
• open "SimpleTestWithTagImport/html/classdoximportedproject_1_1DoxygenErrors.html"

(or open each "index.html" file and search for "DoxygenErrors", which is a class that shows the same samples as before.)

• Note the "final sample" in the text, the reference to "ALIB_COMPILATION_FLAGS"
  which works when the tag file is imported, but does not work with the original project.
  (It had worked for years with previous doxygen versions)

If you want to compile the dox yourself, you have to

• edit "makedox.sh" and set the path to your local current doxygen binary
• run makedox.sh
  (The script is so simple, if you work under windows, it should be no thing to make a bat from it)

Additional Notes:

• If you want to see more samples of non-working links, search for occurences of
  "\doxlinkproblem"
  This is an alias that I have created. Here I provide the html file and the anchor name
  that I manually retrieved from the tag file. Its roughly 100 search results, but of-course
  many link to the same problematic cases.

  I do not know if I had myself made errors with the other ones.
  Therefore, you should not investigate into that.

  When we have found out how to fix the current samples, I will try to resolve the others and
  look for myself if they are fixed then.

• The current git version of doxygen produces a new error, which is not present in the
  current release 1.10:

  windowsconsolelogger.cpp:79: warning: no matching class member found for
  WindowsConsoleLogger(const NString &name)
  Possible candidates:
  'ALIB_API WindowsConsoleLogger::WindowsConsoleLogger(const NString &name=nullptr)'
  at line ALib/src/alib/alox/loggers/windowsconsolelogger.hpp:102

  Well, yes, this is the right single candidate!

• I have deleted all ".svg" files in the html output of the ALib project in attached tar.gz file. Otherwise it was too huge to be allowed to upload

doxygenALibRefTag2.tar.gz

[AlexWorx]

* The current git version of doxygen produces a new error, which is not present in the
  current release 1.10:
  windowsconsolelogger.cpp:79: warning: no matching class member found for
  WindowsConsoleLogger(const NString &name)
  Possible candidates:
  'ALIB_API WindowsConsoleLogger::WindowsConsoleLogger(const NString &name=nullptr)'
  at line ALib/src/alib/alox/loggers/windowsconsolelogger.hpp:102
  Well, yes, this is the right single candidate!

Forget about this one: Here, doxygen is right to complain. The only thing is that it did not complain with 1.10. I forgot a namespace.... Sorry!

[albert-github]

Do I understand it correctly that all problems are fixed and that on the doxygen side nothing is open?

[AlexWorx]

Hello Albert, unfortunately not. My second post of March 20 concerned only the second bullet of the "Additional Notes" section of my long post of March 20 reply.
Although my text is quite long, I think, it should be quite easy to reproduce the errors now.