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 701771 - EXPAND_AS_DEFINED not working with some project structures
EXPAND_AS_DEFINED not working with some project structures
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: documentation
1.8.4
Other Windows
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2013-06-07 05:32 UTC by geoff
Modified: 2013-08-23 15:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Problem demonstration with included doxyfile. (4.49 KB, application/zip)
2013-06-07 05:32 UTC, geoff
Details

Description geoff 2013-06-07 05:32:04 UTC
Created attachment 246225 [details]
Problem demonstration with included doxyfile.

The attached example expands to this:

    headers/test.hpp
    source/test.cpp
    tests/demo.cpp
    doc/doxyfile

This reflects the structure of my C++ project within the project root.

In some circumstances this can cause EXPAND_AS_DEFINED to fail to expand a specified macro.  The problem is not consistent, it can come and go depending on where the header that defines the macro is included.

In the attached example headers/test.hpp is included in both source/test.cpp and in tests/demo.cpp - and as a result MYMACRO (defined in headers/test.hpp) does NOT expand when it appears in tests/demo.cpp.

If you then go into source/test.cpp and comment out the include statement then doxygen WILL expand MYMACRO inside tests/demo.cpp.
Comment 1 Dimitri van Heesch 2013-06-08 15:04:20 UTC
This was a tricky bug. I could not reproduce the problem on MacOSX. The Windows build did show the problem however. 

It appears that using ../ as INCLUDE path caused the problem. Doxygen translated this to ..\ which was ultimately passed to the windows function _wstat. But _wstat returned an error, causing it not been seen as a directory that could be used for searching includes.

I'll fix it by first cleaning the path, which will turn ../ into ..
You could try this as a workaround in your config file as well.
Comment 2 geoff 2013-06-08 15:28:49 UTC
The "../" in the doxyfile was done to try and make the attached project as self-sufficient and portable as I could.  In my actual project doxyfile I am using explicit paths.

I just checked and can see that and INCLUDE_PATH of:

   D:/path/project/

shows the problem, while

   D:/path/project

does not.

I was able to reproduce this here on both my copy of the attached example and - more importantly - on my real project.

Well done and thank you very much Dimitri.  Not only did you find the bug, you have supplied an easy to use work around between now and the next update.
Comment 3 Dimitri van Heesch 2013-08-23 15:04:17 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.5. 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.