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

EXPAND_AS_DEFINED not working with some project structures (Origin: bugzilla #701771) #5201

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 normal in component documentation for ---
Reported in version 1.8.4 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2013-06-07 05:32:04 +0000, geoff@telesiscomputing.com.au wrote:

Created attachment 246225
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.

On 2013-06-08 15:04:20 +0000, Dimitri van Heesch wrote:

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.

On 2013-06-08 15:28:49 +0000, geoff@telesiscomputing.com.au wrote:

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.

On 2013-08-23 15:04:17 +0000, Dimitri van Heesch wrote:

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.

@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