I've tested the branch and the rebuild issue is fixed, thanks!
From the initial bug report, there is still the non-blocking error log happening during the dyndep generation.
Error
log that doesn't fail the build)With the following project:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.28)
project(moduletest LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)
add_library(modulelib)
target_sources(modulelib PRIVATE FILE_SET CXX_MODULES FILES lib.cpp)
add_executable(moduleexe)
target_sources(moduleexe PRIVATE main.cpp)
target_link_libraries(moduleexe PRIVATE modulelib)
// lib.cpp
export module mylib;
// main.cpp
import mylib;
int main() { return 0; }
I get the following errors:
[ 50%][4/8] Generating CXX dyndep file CMakeFiles/moduleexe.dir/CXX.dd
CMake Error: Unable to use module 'mylib' as it is 'PRIVATE' and therefore not accessible outside of its owning target.
[ 87%][7/8] Building CXX object CMakeFiles/moduleexe.dir/main.cpp.o
FAILED: CMakeFiles/moduleexe.dir/main.cpp.o
/usr/lib/ccache/clang++-17 -g -std=c++20 -fcolor-diagnostics -MD -MT CMakeFiles/moduleexe.dir/main.cpp.o -MF CMakeFiles/moduleexe.dir/main.cpp.o.d @CMakeFiles/moduleexe.dir/main.cpp.o.modmap -o CMakeFiles/moduleexe.dir/main.cpp.o -c /home/sjoubert/test/cppmodule/main.cpp
/home/sjoubert/test/cppmodule/main.cpp:1:8: fatal error: module 'mylib' not found
1 | import mylib;
| ~~~~~~~^~~~~
1 error generated.
ninja: build stopped: subcommand failed.
I would expect the build to stop at the first "CMake Error" and not proceed to a compilation that we know will fail. I'm guessing the error is printed but that the actual command is considered "successful" from its exit code.
Fixing the FILE_SET visibility to PUBLIC I still get the following error:
[ 0%][0/1] Re-running CMake...
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /home/sjoubert/test/cppmodule/build
[ 50%][1/2] Building CXX object CMakeFiles/moduleexe.dir/main.cpp.o
FAILED: CMakeFiles/moduleexe.dir/main.cpp.o
/usr/lib/ccache/clang++-17 -g -std=c++20 -fcolor-diagnostics -MD -MT CMakeFiles/moduleexe.dir/main.cpp.o -MF CMakeFiles/moduleexe.dir/main.cpp.o.d @CMakeFiles/moduleexe.dir/main.cpp.o.modmap -o CMakeFiles/moduleexe.dir/main.cpp.o -c /home/sjoubert/test/cppmodule/main.cpp
/home/sjoubert/test/cppmodule/main.cpp:1:8: fatal error: module 'mylib' not found
1 | import mylib;
| ~~~~~~~^~~~~
1 error generated.
ninja: build stopped: subcommand failed.
CMake was successfully retriggered but the module information were not updated and the build still fails.
A ninja clean && ninja
will properly build successfully.
Also note that changing back from PUBLIC to PRIVATE after a successful build will not produce an error (ninja actually says no work to do
since nothing changed in the build graph)
Versions:
With CMake 3.27, a fix for #24857 has been introduced: During Unity builds, CMake now inserts the following line into CMake-generated C files:
// NOLINTNEXTLINE(bugprone-suspicious-include)
Unfortunately, this breaks the compilation if C extensions are off in gcc using set(CMAKE_C_EXTENSIONS OFF)
:
unity_0_c.c:3:1: error: C++ style comments are not allowed in ISO C90
3 | // NOLINTNEXTLINE(bugprone-suspicious-include)
| ^
Thanks
Sylvain Joubert (09025415) at 15 Aug 10:04
Unity: use C-style comments to work both with C and C++
... and 8159 more commits
D:\builds\blahblah\Unity\unity_2_cxx.cxx:3:11: warning: suspicious #include of file with '.cpp' extension [bugprone-suspicious-include]
#include "D:/tests.cpp"
^
It would be nice if the unity file that cmake generates could also add //NOLINTNEXTLINE(bugprone-suspicious-include) above each #include to squash this warning.
Unity builds intentionally include entire source files.
Fixes: #24857
Sylvain Joubert (030fea07) at 27 Apr 11:08
Ignore clang-tidy 'bugprone-suspicious-include' warning in unity so...
... and 7074 more commits
Good point. Updated.
Sylvain Joubert (ca2a84c3) at 25 Apr 07:04
TestDriver: Fix 'misc-use-anonymous-namespace' warning from clang-t...
Sylvain Joubert (b6fd098a) at 25 Apr 05:32
TestDriver: Fix 'misc-use-anonymous-namespace' warning from clang-t...
... and 27 more commits
The macro way may be somewhat unclear to read, but I don't really have a strong preference. I'm fine reworking the MR to suit whatever approach is decided.
clang-tidy 16 introduced a new check that warns about static global variable and functions and suggest using anonymous namespace instead.
clang-tidy does not warn about const variables so making the variable const was enough.
But for the two functions ignoring the warning is the easiest fix since using an anonymous namespace is not possible for C compatibility of the file and using conditional macros for a begin/end namespace and the static
keyword seems worse.
Sylvain Joubert (b220d774) at 13 Apr 06:01
TestDriver: Fix 'misc-use-anonymous-namespace' warning from clang-t...
... and 6998 more commits
Directory-level rules in CMakeFiles/Makefile2
were previously
previously written by each directory's local generator using its own
decision for using relative or absolute paths.
Since !7020, each local generator
explicitly models the relationship between its source and build paths,
and uses this to determine when it is safe to use relative paths.
Because add_subdirectory
supports arbitrary placement of the source
and build directories, different local generators may have different
relationships between their source and build paths. This can cause
disagreement among rules written to CMakeFiles/Makefile2
.
Restore consistency by always using the root local generator to write
rules to CMakeFiles/Makefile2
. Relative paths should always be
expressed w.r.t. the top-level build directory since that is the working
directory in which the make
tool processing the file will run.
Fixes: #23814
Backport: release
I just tested this fix, it works again. And I also figured why I could not reproduce it locally. Turns out I'm using an in source build/binary folder locally and the issue only triggers with an out-of-source build (which I do on my CI) Thanks for the fix!
Additional context in light of !7020 (merged):
/[full/path]/
source dir is a docker mount point (-v
option) from outside the containerI'm trying to reproduce it locally using the CI docker image and reduce it but it's not that simple unfortunately.
However, here is additional information that could help narrow things.
On my local working setup, the Makefiles contain "relative" targets:
// grep results from 'grep -rn Generated/Build/all *' in the build dir
CMakeFiles/Makefile2:67:all: Generated/Build/all
CMakeFiles/Makefile2:1200:Generated/Build/all: Generated/Build/Lib/all
CMakeFiles/Makefile2:1201:Generated/Build/all: Generated/Build/App/all
CMakeFiles/Makefile2:1202:Generated/Build/all: Generated/Build/Test/all
CMakeFiles/Makefile2:1203:.PHONY : Generated/Build/all
Generated/Build/Makefile:146: cd /[full/path]/build && $(MAKE) $(MAKESILENT) -f CMakeFiles/Makefile2 Generated/Build/all
On the broken CI, they contain some "absolute" targets names, but these are not consistent as the all
dependency is still relative:
// grep results from 'grep -rn Generated/Build/all *' in the build dir
CMakeFiles/Makefile2:67:all: Generated/Build/all
CMakeFiles/Makefile2:1200:/[full/path]/build/Generated/Build/all: /[full/path]/build/Generated/Build/Lib/all
CMakeFiles/Makefile2:1201:/[full/path]/build/Generated/Build/all: /[full/path]/build/Generated/Build/App/all
CMakeFiles/Makefile2:1202:/[full/path]/build/Generated/Build/all: /[full/path]/build/Generated/Build/Test/all
CMakeFiles/Makefile2:1203:.PHONY : /[full/path]/build/Generated/Build/all
Generated/Build/Makefile:146: cd /[full/path]/build && $(MAKE) $(MAKESILENT) -f CMakeFiles/Makefile2 /[full/path]/build/Generated/Build/all
Given that, the Generated/Build/all
target indeed has no rules associated.
Hopefully this can ring a bell on a recent work. With a quick glance on the 3.24 git history, the only thing that I see may be !7020 (merged) but I have no idea if it is actually relevant.
I have somewhat "weird" setup that worked so far and now breaks with v3.24.0-rc5 (or any rc)
I have a CMake project that generates code in a sub-folder of the build tree (let's call it <build>/Generated
, in practice I have a dozen generated folders). This generated folder is a full C++/CMake based project that is immediately add_subdirectory(${CMAKE_CURRENT_BINARY_DIR}/Generated ${CMAKE_CURRENT_BINARY_DIR}/Generated/Build)
after generation in the main project. So I have a generated sub-dir in the binary dir and its associated binary dir as a sub-folder of itself.
I now get the following error: gmake[1]: *** No rule to make target 'Generated/Build/all', needed by 'all'. Stop.
This only happens:
I've found a workaround: placing the associated binary dir alongside the generated dir instead of being a child. So add_subdirectory(${CMAKE_CURRENT_BINARY_DIR}/Generated ${CMAKE_CURRENT_BINARY_DIR}/Generated_build)
still works correctly.
I have some ExternalProject
s on my build that use an autotools build system (notably libxml2
and libuuid
). The introduction of the NEW
behavior made their build fail with errors like this one:
configure.ac:58: error: version mismatch. This is Automake 1.16.3,
configure.ac:58: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:58: comes from Automake 1.16.1. You should recreate
configure.ac:58: aclocal.m4 with aclocal and run automake again.
I'm assuming that setting newer timestamp on some autoconf files now triggers some regen/rebuild that did not trigger before (even on a clean build). I have explicitly set DOWNLOAD_EXTRACT_TIMESTAMP ON
to these projects and everything is working again.
Is this expected and my fix the correct way to do it? I'm ok with explicitly setting this. But since it seems to affect multiple (not all) of my autoconf dependencies, I though I would let you know, others might have the same experience.