New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include files not found in include path, or duplicate entry of include file is inserted (Origin: bugzilla #641336) #4137

Closed
doxygen opened this Issue Jul 2, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

status RESOLVED severity major in component general for ---
Reported in version 1.7.3 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2011-02-03 11:52:44 +0000, Michael Stangeland wrote:

Created attachment 179982
Minimum Project demonstrating strange behavior, html output included

Perhaps related to BUG535045 (https://bugzilla.gnome.org/show_bug.cgi?id=535045)

My rather large project that I am assigned to maintain spans several folders. There are some include files that don't seem to be found (not clickable). The odd time the generated documentation also indicates files included twice, although the source code only has it once. Of the duplicate include files, one is with a clickable link and the other is not clickable.

This seriously hinders my confidence in the Doxygen output as it seems to be inconsistent. I spent several days trying to characterize what is going on, but I'm still lost.

On 2011-02-05 23:10:36 +0000, Dimitri van Heesch wrote:

Confirmed. Should be fixed in the next subversion update.

On 2011-03-28 14:18:54 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.7.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.

On 2011-05-17 11:34:37 +0000, Libor Morkovsky wrote:

The change in pre.l:readIncludeFile just changed manifestation of this bug, but did not fix it: some includes with realtive paths containing '../' still fail to be found as fileDefs.

Quick fix:
Use (newly constructed) absolute path for findFileDef() if
fs=findFile() returns NULL

Proposed solution:
Do not throw away the result of findFile/checkAndOpenFile if the file was already included, use the already constructed absolute path to find the filedef for the given file.

On 2011-09-21 15:49:24 +0000, Thomas Langen wrote:

Created attachment 197166
absIncFileName instead of incFileName for findFileDef

On 2011-09-21 15:49:58 +0000, Thomas Langen wrote:

Using the absolute include file name for the invocation of findFileDef instead of the original file name avoids finding problems when the original file name starts with "../" (or "..\", for Windows). The enclosed patch for src/pre.l for version 1.7.5.1 seems to solve that problem.

On 2011-09-25 12:18:50 +0000, Dimitri van Heesch wrote:

Hi Thomas,

Thanks for the patch, I'll include the patch in the next subversion update.

On 2011-12-03 18:22:48 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.7.6. 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.

@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment