After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693406 - Doxygen should support tag files with same name
Doxygen should support tag files with same name
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
1.8.3.1
Other Windows
: Normal enhancement
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2013-02-08 09:43 UTC by mejohansen
Modified: 2015-08-29 15:33 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
TAG file issue (89.00 KB, application/zip)
2013-02-08 09:43 UTC, mejohansen 		Details

Description mejohansen 2013-02-08 09:43:01 UTC 
Created attachment 235492 [details]
TAG file issue

As an example, if one adds this to Doxyfile:

TAGFILES = \
    ../A/tags=../../A/html \
    ../B/tags=../../B/html \
    ../C/tags=../../C/html

...only links to documentation in C will work while links to A and B will use the base URL of C and are therefore broken.
Attached you will find an example project.

Dimitri has confirmed that this is an issue because the tag file names are used to identify the link target.
So if two or more tag files have the same name, the base URL of the last of these in TAGFILES will be used for all of them.

Doxygen should support tag files with identical names, e.g., by identifying the link targets by tag file path (directory + filename).
Comment 1 Dimitri van Heesch 2013-02-09 18:00:46 UTC 
Confirmed. Should be fixed in the next subversion update.
Comment 2 Dimitri van Heesch 2013-05-19 12:35:41 UTC 
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.4. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant.
Comment 3 Daniel Elstner 2015-08-29 15:04:19 UTC 
This change broke install-time rewriting of documentation references in our custom doc-install.pl script in mm-common. We are now working around the issue by stripping the tagfile directory prefix in a post-processing step, so it's no longer a problem for us.

However, another visible side effect of this change is that the generated HTML files are now full of local path references leaked from the build environment, which is rather ugly.