-
Notifications
You must be signed in to change notification settings - Fork 87
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
STRIP_FROM_INC_PATH #137
Comments
Hi! I'm actually using this feature myself, but together with |
Actually the behaviour I'm searching for is to remove a prefix to all include paths: I have a module based C++ Framework which is setup with straightforward custom CMake macros in order to have all modules available under the same include directory so that if user wants to access compression it is "#include <Framework/Compression/Whatever.hpp>" like any other tool in the Framework. However when generating documentation I have to specify the include path for each of my modules. This then will add an unwanted "XXX/include/Framework/somepath" prefix where XXX is the module root folder. I checked the python source code but it does not use the "imports" attribute of Doxygen instead it uses "location" which is the full path including the unwanted prefix hence the code I posted. |
Still trying to understand your use case ... so you need
Wouldn't it be better to use the |
Yeah I'm not entirely sure if imports will work in all cases. I know that if I had to change the include path on my projects, I remember always just applying a post process script to fix the include paths, Doxygen has not always been very good at fully resolving include graphs especially in large projects with custom build systems... |
(Sorry for such a long delay.)
Interesting. Contrary to your experience, I always managed to convince it to make the paths work. I still think should be solved on Doxygen side, and the script just consuming the cleaned up paths from Doxygen output, and so I'm hesitant to merge the PR. Is your project public? Or do you have a small repro case where Doxygen alone won't be able to correctly apply the setting? |
Hello, here is a link to one of the public repositories I'd like to apply the tool: https://github.com/BlockProject3D/Framework |
Thanks, does it have a Doxyfile so I could try building the docs locally and investigate? I checked a few branches but didn't find one. |
Oh yeah, there's indeed no Doxyfile as the documentation is not yet part of the project (working on it in branch DocUpdate). |
Hi, sorry about the extreme delay again. 2020 is a strange year. I cloned the project, took the Doxyfiles, edited them to have # This got added
STRIP_FROM_PATH = Base/include Compression/include/
# This was already there
STRIP_FROM_INC_PATH = Base/include/ Compression/include/ and the result is the following: So, to me at least, this works as expected. The Files list also doesn't show any extra ... except that the |
Thank you, will try when I'll have more time |
Sorry for the long delay, I had a lot of work to do and recently I got into a lot of issues with GitHub which used to be the master repository. I started to migrate the master repositories to GitLab which fullfills much better my needs for my project in addition of offering a MUCH better support for Pages. I just tried what you proposed and it seems to work. You can see the result on the new doc site: https://bp3d.gitlab.io/framework/docs I'll close this issue as this seem fixed. I will probably open a new one for a different problem. |
When documenting a class, a struct or an union, Doxygen allows the user to specify a custom header. Doxygen doc: \class <name> [<header-file>] [<header-name>] \struct <name> [<header-file>] [<header-name>] \union <name> [<header-file>] [<header-name>] The specified <header-name> can be retrieved between the <includes></includes> tag of the generated xml for the classes/structs/unions constructs. This patch uses <header-name> instead of the default path extracted from the <location file="xx"/> without modifying the location. This also fixes mosra#137 for these three constructs when the user does not define the <header-file>/<header-name>, because the value present inside the <includes> tag is stripped using the Doxygen STRIP_FROM_INC_PATH option, whereas <location file="xx"/> is not. Hence, there is still an issue for namespaces, free functions, enums, typedefs, variables and defines which are not part of a class/struct or union.
When documenting a class, a struct or an union, Doxygen allows the user to specify a custom header. Doxygen doc: \class <name> [<header-file>] [<header-name>] \struct <name> [<header-file>] [<header-name>] \union <name> [<header-file>] [<header-name>] The specified <header-name> can be retrieved between the <includes></includes> tag of the generated xml for the classes/structs/unions constructs. This patch uses <header-name> instead of the default path extracted from the <location file="xx"/> without modifying the location. This also fixes mosra#137 for these three constructs when the user does not define the <header-file>/<header-name>, because the value present inside the <includes> tag is stripped using the Doxygen STRIP_FROM_INC_PATH option, whereas <location file="xx"/> is not. Hence, there is still an issue for namespaces, free functions, enums, typedefs, variables and defines which are not part of a class/struct or union.
Hello,
I would like to thank for such great C++ documentation tool with modern UI.
I noticed however that the STRIP_FROM_INC_PATH Doxygen variable is ignored. Is that expected?
In the case this is just some forgot variable, I replaced the code block line 186 to 190 to the following:
Python displayName = file if ("STRIP_FROM_INC_PATH" in state.doxyfile): strip = state.doxyfile["STRIP_FROM_INC_PATH"] displayName = file.replace(strip, "") return (html.escape('<{}>'.format(displayName)), state.compounds[state.includes[file]].url)
In addition I added mapping for STRIP_FROM_INC_PATH to the state.doxyfile.
Can this feature be accepted? If so, I can make a pull request.
The text was updated successfully, but these errors were encountered: