Skip to content
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

Closed
Yuri6037 opened this issue May 12, 2020 · 11 comments · May be fixed by #139
Closed

STRIP_FROM_INC_PATH #137

Yuri6037 opened this issue May 12, 2020 · 11 comments · May be fixed by #139

Comments

@Yuri6037
Copy link
Contributor

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 mosra added this to TODO in Doxygen theme via automation May 12, 2020
@mosra
Copy link
Owner

mosra commented May 12, 2020

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
Copy link
Contributor Author

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
Copy link
Owner

mosra commented May 13, 2020

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
Copy link
Contributor Author

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
Copy link
Owner

mosra commented Jun 9, 2020

(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
Copy link
Contributor Author

Yuri6037 commented Jun 9, 2020

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

@mosra
Copy link
Owner

mosra commented Jun 9, 2020

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
Copy link
Contributor Author

Yuri6037 commented Jun 9, 2020

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
Copy link
Owner

mosra commented Nov 7, 2020

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:

image

So, to me at least, this works as expected. The Files list also doesn't show any extra XXX/include dirs anymore:

image

... 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
Copy link
Contributor Author

Yuri6037 commented Nov 8, 2020

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

@Yuri6037
Copy link
Contributor Author

Yuri6037 commented Mar 8, 2021

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.

@Yuri6037 Yuri6037 closed this as completed Mar 8, 2021
Doxygen theme automation moved this from TODO to Done Mar 8, 2021
Syllo added a commit to Syllo/m.css that referenced this issue Jun 12, 2021
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.
Syllo added a commit to Syllo/m.css that referenced this issue Jun 12, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Doxygen theme
  
Done
Development

Successfully merging a pull request may close this issue.

2 participants