STRIP_FROM_INC_PATH

[Yuri6037]

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.

[mosra]

Hi!

I'm actually using this feature myself, but together with STRIP_FROM_PATH (see for example the magnum Doxyfile). When used like this, it "just worked" on the Doxygen side, without any extra work needed in the m.css processing script.

[Yuri6037]

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.

[mosra]

Still trying to understand your use case ... so you need STRIP_FROM_PATH to be different than STRIP_FROM_INC_PATH? Otherwise I'd just put XXX/include to both, like I showed in the link above, and that would work -- the XML will have the path stripped already, and nothing to be done in the script here.

I checked the python source code but it does not use the "imports" attribute of Doxygen instead it uses "location"

Wouldn't it be better to use the imports attribute then? Like, I'm trying to have Doxygen do most of the work for me and only if there's no other option I take the Doxyfile options and use them myself. In this case I think Doxygen should be able to do this on its own, without additional patching on the script side. (You can try patching the code to use imports instead of location. If all tests still pass, great, I can switch to it. But I'm pretty sure I had a good reason to not use location, because it was buggy in some way.)

[Yuri6037]

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... I checked the code and could not find an easy way to update to use imports instead of location. The good thing of location is it's available in a lot more contexts than just imports. There might be better ways to support that, I just thought applying this patch to be the simplest and probably the best to avoid breaking changes.

[mosra]

(Sorry for such a long delay.)

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

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?

[Yuri6037]

Hello, here is a link to one of the public repositories I'd like to apply the tool: https://github.com/BlockProject3D/Framework

[mosra]

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.

[Yuri6037]

Oh yeah, there's indeed no Doxyfile as the documentation is not yet part of the project (working on it in branch DocUpdate). Here is a ZIP of the two Doxyfile (one for MCSS and one for the Framework) FDoc.zip

[mosra]

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 XXX/include dirs anymore:

... except that the Framework dir is there twice, once for Base and once for Compression, but that's the same I have with Magnum as well and IIRC the same was when I was using the vanilla Doxygen theme back in the day. To distinguish them from each other I just specified which project is the dir part of in the brief docs.

[Yuri6037]

Thank you, will try when I'll have more time

[Yuri6037]

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.