xmake-io
`user_headerunit` example failing to compile
Xmake Version
v2.9.5+dev.124e091f9
Operating System Version and Architecture
Arch Linux @ 6.10.11
Describe Bug
Xmake fails to import header.hpp while building the project.
Expected Behavior
I should be able to import header units in my code (?, I don't know if it's fully implemented in xmake).
Project Configuration
add_rules("mode.release", "mode.debug")
set_languages("c++latest")
set_runtimes("c++_shared")
set_toolchains("clang")
add_headerfiles("src/*.hpp")
add_cxxflags("-fmodules", "-fimplicit-modules", "-fimplicit-module-maps")
set_policy("build.c++.modules", true)
target("user_headerunit")
set_kind("binary")
add_files("src/*.cpp", "src/*.mpp")
Additional Information and Error Logs
I'm using clang, libc++ and clang-scan-deps from trunk (20.0.0).
checking for architecture ... x86_64
[ 0%]: <user_headerunit> generating.module.deps src/main.cpp
[ 0%]: <user_headerunit> generating.module.deps src/hello.mpp
[ 0%]: <user_headerunit> generating.module.deps /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib
64/../share/libc++/v1/std.cppm
[ 0%]: <user_headerunit> generating.module.deps /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib
64/../share/libc++/v1/std.compat.cppm
error: Error while scanning dependencies for src/main.cpp:
src/main.cpp:4:8: error: header file "header.hpp" (aka 'src/header.hpp') cannot be imported because it is not kno
wn to be a header unit
to use header unit u need to enable fallback scanner (which enable other problem like C++ version detection), clang-scan-deps doesn't support header unit currently
headerunit are highly experimental on clang, i suggest to use only named modules
Any update on this? I just tried with clang-scan-deps-22 and the issue is still there. Has the header unit part of clang-scan-deps settled/become less experimental? If so, what would need to be done in xmake? If not, is there a current LLVM/clang/clang-scan-deps issue which this depends on? (the one mentioned before seems to be closed)
I would like an update to this issue too.
An update from ME is that I gave up on C++ 🙌
Any update on this? I just tried with clang-scan-deps-22 and the issue is still there. Has the header unit part of clang-scan-deps settled/become less experimental? If so, what would need to be done in xmake? If not, is there a current LLVM/clang/clang-scan-deps issue which this depends on? (the one mentioned before seems to be closed)
There is still no support of header unit in clang-scan-deps or in gcc scanner, it's never been experimental, it's just not implemented
and unlikely implemented in a near future so my advice is the same, don't try to use headerunits, only use named modules
There is still no support of header unit in clang-scan-deps or in gcc scanner, it's never been experimental, it's just not implemented
So, the correct path would be to either get the llvm people to implement it or implement them myself (probably the first step would be to get them to un-incomplete llvm/llvm-project#65903).
and unlikely implemented in a near future so my advice is the same, don't try to use headerunits, only use named modules
mwrg... I tried creating named modules to wrap the libraries and using every single class, but that was definitely not optimal. native support for headerunits would of course be much better
So, the correct path would be to either get the llvm people to implement it or implement them myself (probably the first step would be to get them to un-incomplete https://github.com/llvm/llvm-project/issues/65903).
yes :/
you can also write a external scanner that's is not dependent of any compiler like we began to do in xmake, but we kept it very simple because it's not really XMake job to do this and it's only a fallback solution (which should not be used anymore in 2025)
@Arthapz Thanks for the update. Just a few questions regarding the support for header units:
- You provided a link to the clang-scan-deps issue where we can monitor the current state of the support in clang. I tried a quick search online but could not find any issue regarding dependency scanning / header units in gcc Do you know of such an issue/link for gcc where we could monitor the progress (of lack thereof) with gcc?
- Is there a documentation page describing how to enable the fallback scanner in xmake that you mentioned? Again a quick search in the docs did not show anything about it.
- Is there any kind of documentation for the problems caused by this fallback scanner? You mentioned something about C++ version detection, but a bit of extra info would be helpful in order to determine if this fallback scanner is actually usable in my (or anyone else's) projects.
@Arthapz Thanks for the update. Just a few questions regarding the support for header units:
1. You provided a link to the clang-scan-deps issue where we can monitor the current state of the support in clang. I tried a quick search online but could not find any issue regarding dependency scanning / header units in gcc Do you know of such an issue/link for gcc where we could monitor the progress (of lack thereof) with gcc? 2. Is there a documentation page describing how to enable the fallback scanner in xmake that you mentioned? Again a quick search in the docs did not show anything about it. 3. Is there any kind of documentation for the problems caused by this fallback scanner? You mentioned something about C++ version detection, but a bit of extra info would be helpful in order to determine if this fallback scanner is actually usable in my (or anyone else's) projects.
1: i didn't found a GCC issue for the p1689 dependency scanner header unit support, here you can find all the C++ modules related issue for gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
2: there is not documentation for it, you can enable it with the policy build.c++.modules.fallbackscanner
3: the falllback scanner run clang / gcc to preprocess the file before parsing it, the issue is that when providing a language flag for C++ >= 20 to clang, it enable module machinery and try to find the compiled dependency, which fail as they are not compiled yet, so our strategy was to strip the flag, but when done, all C++20 core language feature will make the preprocess step fail (like deducing this or concepts)
this problem doesn't affect fallback scanner with gcc
but fallback scanner is deprecated and shouldn't be used as it's a simple, naive parsing and isn't really tested, it should be used for any real project, it was usefull when clang-scan-deps and gcc didn't supported p1689, now it's not usefull
headerunit is a half baked feature that will surely need some change before it's usable, you can see https://www.youtube.com/watch?v=_LGR0U5Opdg (a CppNow conference made by the CMake guy that work on C++ modules)
@Arthapz Thanks for the feedback!
-
I did find one this GCC issue that seems to be related to dependency scanning and header units. I am leaving the URL just in case someone wants to track the (lack of) GCC progress: Bug 109718 - Dependency generation for header-units and modules not possible
-
Thanks for the policy key value. I did find it earlier today after looking into the source code and even tried it by calling
set_policy ("build.c++.modules.gcc.fallbackscanner", true)
However it did fail with various errors, initially
error: circular modules dependency detected!
(in fact there are no real circular dependencies, so the scanner is wrong)
Then after running xmake build several times the error changes to
fatal error: unknown compiled module interface: no such module
So I guess you are right that the fallback scanner is not very usable at the moment.
- Thanks for the detailed explanation about the problems with the fallback scanner. I also found your earlier message about it here: https://github.com/xmake-io/xmake/issues/6769#issuecomment-3266566914 and also looked into the Xmake source code, so I guess you are right that header units are not usable with Xmake at the moment (nor with any other build system for that matter).
Its a pity since header units are a rather handy feature, but I guess there is no helping, at least until the compilers fix their dependency scanning.