Skip to content

[doxy] Enable compilation of macros #10195

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

Closed
wants to merge 31 commits into from

Conversation

ferdymercury
Copy link
Collaborator

This Pull request:

Changes or fixes:

Allows macros to be compiled when building docu, as suggested by couet in #10004 (review)

Checklist:

  • tested changes locally
  • updated the docs (if necessary)

@phsft-bot
Copy link

Can one of the admins verify this patch?

@couet
Copy link
Member

couet commented Mar 22, 2022

In #10004 (review) I mean the other .C macros in the doxygen/folder, this used to make the doc. Not all the tutorials.

@ferdymercury ferdymercury marked this pull request as draft March 22, 2022 12:37
@ferdymercury
Copy link
Collaborator Author

ferdymercury commented Mar 22, 2022

In #10004 (review) I mean the other .C macros in the doxygen/folder, this used to make the doc. Not all the tutorials.

Oh, I see. But those macros in the doxygen folder call themselves another macros, so I was just updating the ones that are being called (not all tutorials explicitly) because otherwise it gives an error when trying to compile them. Should I revert those changes? Is there a downside of adding the headers?

@Axel-Naumann
Copy link
Member

We intentionally keep macros "illegal C++": we have a C++ interpreter and we should benefit from this, removing parts of C++ not needed for interactive use, especially for tutorials. We find this simplifies the tutorials. We have exceptions for tutorials where we believe many uses will be compiled.

Being able to compile the tutorials isn't a benefit in and by itself. This PR here came out of #10004 which claims "Precompiles C++ script to potentially speedup (slightly) documentation building". If that's indeed correct then that's a bug in cling. cling must be as fast as compiled code (if using the same optimizer, the same clang version as cling links against etc). So I'd like to better understand the motivation of this?

@ferdymercury
Copy link
Collaborator Author

The main motivation concerning speedup is that currently, the documentation takes between 5 and 7 hours to build, which makes it hard to debug and improve.

The 'slow part' happens in 'filter.cxx' (which does some parsing that slows down doxygen), as well as when the tutorials are run.

That being said, I did not benchmark if pre-compiling makes things considerably faster, so maybe this PR is not worth it, I agree...

@ferdymercury
Copy link
Collaborator Author

On the other hand, I have prepared a rehauled-version that is thread-safe so that doxygen can run in parallel: #9966 (comment)

(Here I did check that things were faster.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants