CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-11-07T01:53:41-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25380Makefiles: Fortran module dependency named via preprocessor DEFINE variable2023-11-07T01:53:41-05:00Jeff HoleMakefiles: Fortran module dependency named via preprocessor DEFINE variableHere is a simple example to show the problem. This is possibly related to #16853.
I am using CMake 3.20.2, GCC toolchain 10 (gfortran 10.3.1), on Rocky Linux 8.8. GNU Make version is 4.2.1.
main.f90:
```fortran
1 #define MODULE_NAME ...Here is a simple example to show the problem. This is possibly related to #16853.
I am using CMake 3.20.2, GCC toolchain 10 (gfortran 10.3.1), on Rocky Linux 8.8. GNU Make version is 4.2.1.
main.f90:
```fortran
1 #define MODULE_NAME MyConstants
2
3 module MODULE_NAME
4 implicit none
5 real(8) :: pi = 3.1415926535897932d0
6 end module
7
8 program main
9 use MODULE_NAME
10 implicit none
11 print *, 'pi = ', pi
12 end program
```
CMakeLists.txt:
```cmake
1 project(test LANGUAGES Fortran)
2 set(CMAKE_Fortran_PREPROCESS YES)
3 add_executable(main.out main.f90)
```
I have both these files in a directory alone, and run:
```bash
cmake -B build
cd build
make
```
And I get the following output:
```bash
Scanning dependencies of target main.out
[ 50%] Building Fortran object CMakeFiles/main.out.dir/main.f90.o
Error copying Fortran module "module_name.mod". Tried "MODULE_NAME.mod" and "module_name.mod".
make[2]: *** [CMakeFiles/main.out.dir/depend.make:7: CMakeFiles/main.out.dir/module_name.mod.stamp] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/main.out.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
```
It appears when CMake determines module dependencies, it doesn't preprocess the file (at least not fully, as suggested in #16853), and it thinks the module name is "MODULE_NAME" instead of "MyConstants".https://gitlab.kitware.com/cmake/cmake/-/issues/24058OPTIMIZE_DEPENDENCIES gives make -j failures for STATIC libraries depending o...2024-02-02T12:53:21-05:00Paul SmithOPTIMIZE_DEPENDENCIES gives make -j failures for STATIC libraries depending on OBJECT librariesI'm using cmake 3.23.1 but a review of the release notes doesn't make me suspect this is fixed in newer versions.
Consider this environment:
```
$ mkdir tst
$ cd tst
$ touch obj.c tst.c
$ cat >>CMakeLists.txt <<EOF
cmake_minimum_require...I'm using cmake 3.23.1 but a review of the release notes doesn't make me suspect this is fixed in newer versions.
Consider this environment:
```
$ mkdir tst
$ cd tst
$ touch obj.c tst.c
$ cat >>CMakeLists.txt <<EOF
cmake_minimum_required(VERSION 3.23)
project(tstopt C)
set(CMAKE_OPTIMIZE_DEPENDENCIES ON)
add_library(obj OBJECT obj.c)
add_library(tst STATIC tst.c)
target_link_libraries(tst PUBLIC obj)
EOF
$ mkdir obj
$ cd obj
$ cmake ..
$ make -j
```
When I run this I get errors from make:
```
make[2]: *** No rule to make target 'CMakeFiles/obj.dir/obj.c.o', needed by 'libtst.a'. Stop.
make[2]: *** Waiting for unfinished jobs....
[ 33%] Building C object CMakeFiles/obj.dir/obj.c.o
[ 66%] Built target obj
[ 66%] Building C object CMakeFiles/tst.dir/tst.c.o
make[1]: *** [CMakeFiles/Makefile2:111: CMakeFiles/tst.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
```
It appears that some prerequisites are missing so that make tries to build `libtst.a` before it has generated makefiles that define a rule for `obj.c.o`... or something? I confess I got lost trying to figure out how the generated make environment is put together.
Note that if I make `tst` a `SHARED` library rather than `STATIC`, I don't see this problem. And, of course, if I disable `CMAKE_OPTIMIZE_DEPENDENCIES` it works correctly as well. And also, if I don't enable parallel builds in make then it works that way too.https://gitlab.kitware.com/cmake/cmake/-/issues/23876Makefiles: Multiple targets not built in parallel2022-09-01T11:49:03-04:00Jonathan SweemerMakefiles: Multiple targets not built in parallelIf I specify multiple `--target` flags on the command line along with `--parallel`, the targets are built sequentially, not in parallel.
For example, if I have the following CMakeLists.txt file:
```cmake
cmake_minimum_required(VERSION ...If I specify multiple `--target` flags on the command line along with `--parallel`, the targets are built sequentially, not in parallel.
For example, if I have the following CMakeLists.txt file:
```cmake
cmake_minimum_required(VERSION 3.24.0)
project(parallel-test LANGUAGES CXX)
add_executable(a a.cpp)
add_executable(b b.cpp)
```
Then the following command runs sequentially.
```console
$ cmake .
$ cmake --build . --target a --target b --parallel
[ 50%] Building CXX object CMakeFiles/a.dir/a.cpp.o
[100%] Linking CXX executable a
[100%] Built target a
[ 50%] Building CXX object CMakeFiles/b.dir/b.cpp.o
[100%] Linking CXX executable b
[100%] Built target b
```
But if I omit the `--target` flags then the project is indeed built in parallel.
```console
$ cmake --build . --parallel
[ 25%] Building CXX object CMakeFiles/a.dir/a.cpp.o
[ 50%] Building CXX object CMakeFiles/b.dir/b.cpp.o
[ 75%] Linking CXX executable b
[100%] Linking CXX executable a
[100%] Built target b
[100%] Built target a
```
Can CMake be changed to build targets in parallel in the first case as well?
CMake version: 3.24.1
OS version: Ubuntu 18.04.6 LTShttps://gitlab.kitware.com/cmake/cmake/-/issues/23804Watcom WMake generator does not support verbose build2022-08-01T10:44:43-04:00MaartenWatcom WMake generator does not support verbose buildUsing the `Watcom WMake` generator, adding `--verbose` to the build command does not enable verbose building.
WMake supports verbose building by adding `-sn`, which enabled the "noisy mode".
See https://open-watcom.github.io/open-watcom...Using the `Watcom WMake` generator, adding `--verbose` to the build command does not enable verbose building.
WMake supports verbose building by adding `-sn`, which enabled the "noisy mode".
See https://open-watcom.github.io/open-watcom-v2-wikidocs/ctools.htmlhttps://gitlab.kitware.com/cmake/cmake/-/issues/23449Should we start recommending Ninja over Makefiles?2022-04-26T10:57:52-04:00Kyle EdwardsShould we start recommending Ninja over Makefiles?Ninja is superior to Make in most respects, and CMake's support for it is quite mature at this point. We offer a multi-config version of the Ninja generator that works on all platforms. You can even bootstrap CMake with Ninja and never e...Ninja is superior to Make in most respects, and CMake's support for it is quite mature at this point. We offer a multi-config version of the Ninja generator that works on all platforms. You can even bootstrap CMake with Ninja and never even have to touch Make.
Perhaps we should consider recommending Ninja over Make? Maybe even set Ninja as the default? (Yes, I know this would be a backwards compatibility nightmare.)https://gitlab.kitware.com/cmake/cmake/-/issues/23425Makefiles: incorrect/missing dependencies when using symbolic links2022-04-15T07:33:51-04:00Deliciously TypedMakefiles: incorrect/missing dependencies when using symbolic links**Symptom:**
After the initial cmake generation and build of my code set, subsequent make invocations would continue to always rebuild what coincidentally happened to be the most time-consuming target, so I started looking into the issu...**Symptom:**
After the initial cmake generation and build of my code set, subsequent make invocations would continue to always rebuild what coincidentally happened to be the most time-consuming target, so I started looking into the issue.
**Discussion/Recommendation:**
(Note: despite the wall of text that it took to find it, the actual issue appears pretty simple.)
Why do you even touch the `.d` output of the compiler instead of directly transplanting the paths into what I assume is supposed to be some sort of cache or such? This leads to precisely these kinds of semantic mismatch issues, instead of doing whatever the compiler does, which instead of replicating the logic, should be left to the compiler anyway - since it's the one that generated the files in the first place, and knows better?
**If it's possible that this is a recurring problem with the many uses of this path handling code in the codebase, perhaps another issue should be opened for tracking fixing this in other occurrences as well?**
**Diagnosis:**
After difficulties finding any useful information in the make -d output, about what was forcing a rebuild of the target in question, I switched to using remake (https://github.com/rocky/remake) which is a make fork that has much better inspection capabilities.
The log output of `remake -d --trace` contained:
```
CMakeFiles/main_chapter0_prog1.dir/build.make:89: update target 'CMakeFiles/main_chapter0_prog1.dir/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/main.cpp.o' due to: /<shortened>/4_prog1/include/std_lib_facilities.h /<shortened>/4_prog1/include/_std_lib_facilities.h
```
This is a nonexistent path. The correct path is `/<shortened>/4_prog1/ppp/include/std_lib_facilities.h` ; note the `ppp` which can be observed in other paths. The correct path is in this case accessed by the following code, which I was experimenting with:
```
// include hack https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
//TODO test both branches
#if defined __has_include
# if __has_include ("../../../include/std_lib_facilities.h")
// include "../../../include/std_lib_facilities.h"
# else
# include "../../../../include/std_lib_facilities.h"
# endif
#else
#error "__has_include not supported when including std_lib_facilities wrapper in >TODO<"
#endif
```
Note that the nature of this code is not actually relevant, this is just to show a bit better what I had set up here.
Note that one of the preprocessor branches is commented out, so there is only one actual branch in use.
This code is supposed to import the header via the path: `/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/../../../../include/std_lib_facilities.h`.
Further investigation by grep shows that the incorrect header location only shows up in these files, and only after the original generation and build, when a second build is attempted:
```
$ grep -irl /<shortened>/4_prog1/include/std_lib_facilities.h
CMakeFiles/main_chapter0_prog1.dir/compiler_depend.make
CMakeFiles/main_chapter0_prog1.dir/compiler_depend.internal
```
After numerous false starts involving strace-ing to attempt to find what causes the incorrect lines to be written and what writes the compiler_depend files, and looking at gcc -MD/-MF/whatever invocations that generate obviously correct dynamic .d dependency files (which contain the _correct_ include path) that are included by make, a friend unstuck me in the debug process and I figured out the rest of the issue:
It was a this point that I realized/it was pointed out to me that the faulty path had exactly the number of path components removed as there were `..` components, instead of interpreting symbolic links. At this point it can be assumed that the behaviour is caused by simply interpeting paths as strings instead of trying to resolve anything.
From previous strace output observation (PID write()s to relevant file or something) I found a variant of the command below, and one assumes it has something to do with the compiler_depend files. I don't remember how I found the execve line for it exactly, but in the knowledge that make must somehow invoke cmake, I found this command line via grep:
```
$ grep -irl cmake_depends
CMakeFiles/main_chapter0_prog1.dir/build.make
CMakeFiles/main_chapter0_prog1.dir/DependInfo.cmake
```
, where `build.make` contains among other things, the following:
```
CMakeFiles/main_chapter0_prog1.dir/depend:
cd /<shortened>/4_prog1/ppp/infra/build && $(CMAKE_COMMAND) -E cmake_depends "Unix Makefiles" /<shortened>/4_prog1/ppp/infra /<shortened>/4_prog1/ppp/infra /<shortened>/4_prog1/ppp/infra/build /<shortened>/4_prog1/ppp/infra/build /<shortened>/4_prog1/ppp/infra/build/CMakeFiles/main_chapter0_prog1.dir/DependInfo.cmake --color=$(COLOR)
```
The cmake_depend 'command mode' appears to be undocumented beyond some StackOverflow questions.
On this command line we can also see a mention of the `DependInfo.cmake` file, which also sounds relevant.
Looking at the `DependInfo.cmake` file we find the following:
```
<omitted>
# The set of dependency files which are needed:
set(CMAKE_DEPENDS_DEPENDENCY_FILES
"/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/GUI.cpp" "CMakeFiles/main_chapter0_prog1.dir/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/GUI.cpp.o" "gcc" "CMakeFiles/main_chapter0_prog1.dir/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/GUI.cpp.o.d"
<omitted> )
<omitted>
```
Searching Google for `CMAKE_DEPENDS_DEPENDENCY_FILES` leads to https://github.com/Kitware/CMake/blob/master/Source/cmLocalUnixMakefileGenerator3.cxx , which looks relevant, so I started digging in here at this point.
Given the name, contents, and invocation, this is probably the code that either writes, or causes something else to write the faulty include path.
This is where I finally find what I'm looking for:
https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmLocalUnixMakefileGenerator3.cxx#L1429
A few lines below mentions can be found of `compiler_depend.make` and `compiler_depend.internal`:
https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmLocalUnixMakefileGenerator3.cxx#L1434
After inspecting this area of the function, and the called functions, it can be seen that the `CheckDependencies` function is what actually creates the dependency entries to be written out later. The definition is located in https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmDependsCompiler.cxx#L29
My compiler is gcc so either this, or the `'custom'` branch handle it; https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmDependsCompiler.cxx#L139
Through the gcc `.d` file handling code, this eventually invokes the `cmSystemTools::CollapseFullPath` function; https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmGccDepfileReader.cxx#L41
This is implemented in `CollapseFullPathImpl`: https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/kwsys/SystemTools.cxx#L3467 , which calls `SystemToolsAppendComponents`; https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/kwsys/SystemTools.cxx#L3442
**This is the code that, as can be seen, indeed does the naive relative path compression, and is the root cause of this problem.** (Well, I imagine. I haven't tried recompiling CMake with a dirty hack of a patch.)https://gitlab.kitware.com/cmake/cmake/-/issues/22848Compiler/TI response file regression with Make generator2023-05-14T16:19:05-04:00Stefano SinigardiCompiler/TI response file regression with Make generatorafter having updated to CMake 3.21 we had to add
```
set(CMAKE_C_USE_RESPONSE_FILE_FOR_LIBRARIES 0)
set(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 0)
```
to our `SitaraToolchain.cmake` toolchain file in order to not have problems at linkin...after having updated to CMake 3.21 we had to add
```
set(CMAKE_C_USE_RESPONSE_FILE_FOR_LIBRARIES 0)
set(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 0)
```
to our `SitaraToolchain.cmake` toolchain file in order to not have problems at linking phase. Otherwise, linking was failing with a message of "path too long" from the `objects1.rsp` file (curious, since response file should be done exactly to avoid this problem...)
see https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6159#note_1045209
note: we use make generator, not ninjahttps://gitlab.kitware.com/cmake/cmake/-/issues/22519Fortran modules: source/config-specific flags are not using for resolving dep...2022-04-06T13:39:02-04:00Igor S. GerasimovFortran modules: source/config-specific flags are not using for resolving dependency graphs with MakefilesIn our project, for some sources specific flags are.
```
set_source_files_properties(SOURCE.F90 PROPERTIES COMPILE_DEFINITIONS FLAG)
```
This flag is used for choosing which module will be used in the code. Unfortunately, `COMPILE_DEFINI...In our project, for some sources specific flags are.
```
set_source_files_properties(SOURCE.F90 PROPERTIES COMPILE_DEFINITIONS FLAG)
```
This flag is used for choosing which module will be used in the code. Unfortunately, `COMPILE_DEFINITIONS` flags are not used when the source code is parsed.
I looked at `cmDependFortran.cxx` and noticed that only flags, defined in `CMAKE_TARGET_DEFINITIONS_Fortran` are applying. It seems to me, that the following code:
https://gitlab.kitware.com/cmake/cmake/-/blob/9e7a0568f604852af6994bebecf580b825b3ae36/Source/cmMakefileTargetGenerator.cxx#L744-766
should be repeated in `cmDependsFortran::WriteDependencies` before `parser` initialization for applying additional flags to each source file separately.https://gitlab.kitware.com/cmake/cmake/-/issues/22483cmake adds space between -D and definition when added with add_definitions2021-07-27T12:09:36-04:00Hertz Adomuscmake adds space between -D and definition when added with add_definitionsHi,
Running cmake version 3.19.6 on Ubuntu with added precompiler definiton:
```cmake
add_definitions(-DFAST_SIM)
```
and running build with verbose outputs it building command contains following
```
/usr/lib/gcc/x86_64-linux-gnu/9/cc...Hi,
Running cmake version 3.19.6 on Ubuntu with added precompiler definiton:
```cmake
add_definitions(-DFAST_SIM)
```
and running build with verbose outputs it building command contains following
```
/usr/lib/gcc/x86_64-linux-gnu/9/cc1plus -v ...-D_GNU_SOURCE -D FAST_SIM ccontour.cpp -m32 ...
```
build fails because gcc ignores FAST_SIM directive.
Thank you for any inforamtion.
Regards,
HAhttps://gitlab.kitware.com/cmake/cmake/-/issues/22073FetchContent: make enter directory messages silent with verbose FetchContent_...2021-04-26T10:18:13-04:00ArcturusFetchContent: make enter directory messages silent with verbose FetchContent_Populateusing cmake version 3.20.1 with Unix Makefile generator verbose output for `FetchContent_Populate` is inconsistent.
# Expected build output:
```bash
-- Populating moderncmake
-- Configuring done
-- Generating done
-- Build files have ...using cmake version 3.20.1 with Unix Makefile generator verbose output for `FetchContent_Populate` is inconsistent.
# Expected build output:
```bash
-- Populating moderncmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build/moderncmake-subbuild
[ 11%] Performing update step for 'moderncmake-populate'
HEAD is now at dea7d40
[ 22%] No patch step for 'moderncmake-populate'
[ 33%] No configure step for 'moderncmake-populate'
[ 44%] No build step for 'moderncmake-populate'
[ 55%] No install step for 'moderncmake-populate'
[ 66%] No test step for 'moderncmake-populate'
[ 77%] Completed 'moderncmake-populate'
[100%] Built target moderncmake-populate
hii
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build
```
# actual build output:
```bash
-- Populating moderncmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build/moderncmake-subbuild
gmake[1]: Entering directory '/tmp/test/build/moderncmake-subbuild'
gmake[2]: Entering directory '/tmp/test/build/moderncmake-subbuild'
gmake[3]: Entering directory '/tmp/test/build/moderncmake-subbuild'
gmake[3]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
gmake[3]: Entering directory '/tmp/test/build/moderncmake-subbuild'
[ 11%] Performing update step for 'moderncmake-populate'
HEAD is now at dea7d40
[ 22%] No patch step for 'moderncmake-populate'
[ 33%] No configure step for 'moderncmake-populate'
[ 44%] No build step for 'moderncmake-populate'
[ 55%] No install step for 'moderncmake-populate'
[ 66%] No test step for 'moderncmake-populate'
[ 77%] Completed 'moderncmake-populate'
gmake[3]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
[100%] Built target moderncmake-populate
gmake[2]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
gmake[1]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
hii
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build
```
The output shows `Entering directory` when the build project is out-of-source. The same does not happen on configure stage.
# Steps to replicate
Test project:
```cmake
cmake_minimum_required(VERSION 3.20)
project(MyProj VERSION 0.1)
include(FetchContent)
set(url https://gist.github.com/c61dbb39bca0e4fb7d1f73b0d66a4fd1)
FetchContent_Populate(moderncmake
# QUIET
GIT_REPOSITORY ${url}
)
message("hi")
```
1. Configure and build with Unix Makefile generator. Configure and build output:
```bash
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Populating moderncmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build/moderncmake-subbuild
[ 11%] Creating directories for 'moderncmake-populate'
[ 22%] Performing download step (git clone) for 'moderncmake-populate'
Cloning into 'moderncmake-src'...
Already on 'master'
Your branch is up to date with 'origin/master'.
[ 33%] Performing update step for 'moderncmake-populate'
HEAD is now at dea7d40
[ 44%] No patch step for 'moderncmake-populate'
[ 55%] No configure step for 'moderncmake-populate'
[ 66%] No build step for 'moderncmake-populate'
[ 77%] No install step for 'moderncmake-populate'
[ 88%] No test step for 'moderncmake-populate'
[100%] Completed 'moderncmake-populate'
[100%] Built target moderncmake-populate
hi
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build
```
2. The project is now up-to-date. Modify `CMakeLists.txt` file and build again (i changed line 13 from `message("hi")` into `message("hii")`. Build output:
```bash
-- Populating moderncmake
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build/moderncmake-subbuild
gmake[1]: Entering directory '/tmp/test/build/moderncmake-subbuild'
gmake[2]: Entering directory '/tmp/test/build/moderncmake-subbuild'
gmake[3]: Entering directory '/tmp/test/build/moderncmake-subbuild'
gmake[3]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
gmake[3]: Entering directory '/tmp/test/build/moderncmake-subbuild'
[ 11%] Performing update step for 'moderncmake-populate'
HEAD is now at dea7d40
[ 22%] No patch step for 'moderncmake-populate'
[ 33%] No configure step for 'moderncmake-populate'
[ 44%] No build step for 'moderncmake-populate'
[ 55%] No install step for 'moderncmake-populate'
[ 66%] No test step for 'moderncmake-populate'
[ 77%] Completed 'moderncmake-populate'
gmake[3]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
[100%] Built target moderncmake-populate
gmake[2]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
gmake[1]: Leaving directory '/tmp/test/build/moderncmake-subbuild'
hii
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/build
```https://gitlab.kitware.com/cmake/cmake/-/issues/21889Makefile generators use wrong relative path for build subdirectories under th...2021-03-07T02:07:48-05:00Stewart D. SmithMakefile generators use wrong relative path for build subdirectories under the source directory but not under the main build directorycmake version 3.20.0-rc1
When setting `FETCHCONTENT_SOURCE_DIR_<ucName>` using the generators "NMake Makefile" and "Unix Makefile", the generated `CMakeFiles/Makefile2` file mixes up relative path names and absolute path names when refe...cmake version 3.20.0-rc1
When setting `FETCHCONTENT_SOURCE_DIR_<ucName>` using the generators "NMake Makefile" and "Unix Makefile", the generated `CMakeFiles/Makefile2` file mixes up relative path names and absolute path names when referring to the target associated with the set `FETCHCONTENT_SOURCE_DIR_<ucName>`.
This does not happen when using the "Visual Studio 16 2019" generator and building the resulting solution.
See my main project CMakeLists.txt ([rtek_CMakeLists.txt](/uploads/d0c2ada3868a8e49b092bd0c9928f0ae/rtek_CMakeLists.txt)), the dependency CMakeLists.txt ([sdslib_CMakeLists.txt](/uploads/1c3acce14c2a324f4164e14044d22929/sdslib_CMakeLists.txt)) and the generated [Makefile2](/uploads/b37c47243b698583644f9273100f3371/Makefile2) attached.
Error:
```
make[1]: *** No rule to make target '../_deps/sdslib-build/CMakeFiles/sdslib.dir/all', needed by 'CMakeFiles/rtek.dir/all'. Stop.
make: *** [Makefile:91: all] Error 2
```
Relevant part of my file structure:
```
repos/
rtek/
_deps/
build/
CMakeFiles/
Makefile2
CMakeLists.txt
sdslib-cpp/
CMakeLists.txt
```
Configure & build steps:
```
cd repos/rtek
cmake -S. -B./build -G"NMake Makefiles" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DFETCHCONTENT_SOURCE_DIR_SDSLIB="../sdslib-cpp"
cmake --build build
```
- I tried using an absolute path with FETCHCONTENT_SOURCE_DIR_SDSLIB, but that had no effect.
Relevant parts of `Makefile2`:
```
# refers to sdslib.dir\all by relative path name
CMakeFiles\rtek.dir\all: ..\_deps\sdslib-build\CMakeFiles\sdslib.dir\all
# ...
# sdslib.dir\all defined by full path name
C:\Users\stewa\source\repos\rtek\_deps\sdslib-build\CMakeFiles\sdslib.dir\all:
# ...
# sdslib-build/all refers to sdslib.dir/all as absolute path
C:/Users/stewa/source/repos/rtek/_deps/sdslib-build/all: C:/Users/stewa/source/repos/rtek/_deps/sdslib-build/CMakeFiles/sdslib.dir/all
```
Doing the following find-and-replace in `Makefile2` fixes the generated build:
- `C:/Users/stewa/source/repos/rtek/_deps/sdslib-build/CMakeFiles/sdslib.dir/all` -> `../_deps/sdslib-build/CMakeFiles/sdslib.dir/all`
- `C:/Users/stewa/source/repos/rtek/_deps/sdslib-build/all` -> `../_deps/sdslib-build/all`Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21867Makefiles: 101% at end of compilation2022-07-05T03:56:25-04:00Yunior PeraltaMakefiles: 101% at end of compilationWhen compiling with cmake I'm getting 101% at the end instead of 100%. I think it may be related to the following lines:
```cmake
add_subdirectory(subdir1 EXCLUDE_FROM_ALL)
set_target_properties(target1 PROPERTIES EXCLUDE_FROM_ALL False...When compiling with cmake I'm getting 101% at the end instead of 100%. I think it may be related to the following lines:
```cmake
add_subdirectory(subdir1 EXCLUDE_FROM_ALL)
set_target_properties(target1 PROPERTIES EXCLUDE_FROM_ALL False)
```
where **target1** is one the the many targets that are configured inside **subdir1**. So basically I want to exclude all targets from **subdir1** except **target1**.
tested with **cmake version 3.20.0-rc2**https://gitlab.kitware.com/cmake/cmake/-/issues/21372Makefiles: Changing CMake versions forces complete rebuild2020-11-07T13:00:43-05:00Andreas ZoufalMakefiles: Changing CMake versions forces complete rebuildI'm not sure if this is the only reason, but at least this looks suspicious to me.
My use-case: I build my project during development using CLion, which comes with an bundled CMake version. But often I build it from command line too (in...I'm not sure if this is the only reason, but at least this looks suspicious to me.
My use-case: I build my project during development using CLion, which comes with an bundled CMake version. But often I build it from command line too (in the same directories), for example all variants (debug, release) before I commit changes. Command line uses python virtualenv, where I have another CMake version installed.
The CMake version (CLion and Python) mismatch in version. I recognized, running CMake with one method has an influence to the other method, then everything is rebuilt there. It took me a long time to realize, that in some generated files this comment is included: `Generated by "Unix Makefiles" Generator, CMake Version X.YZ`. I guess this is the culprit for the rebuild? I found flags.make, build.make, depend.make for example.
I'm not sure whats the reason to add the version number here, but if it is the only reason for invalidating the compiled files, I would prefer to remove the version information from the comment.
Am I right with my observation? Or are there other, unavoidable reasons?
Please don't recommend to use the same CMake executable in all build variants, this is my current workaround. But is annoying, I have to change CLion settings for example.https://gitlab.kitware.com/cmake/cmake/-/issues/20366FindOpenMP fails if the build directory contains a colon character (:)2020-02-24T11:22:39-05:00Davide MancusiFindOpenMP fails if the build directory contains a colon character (:)Minimal reproducer:
```
$ cat >CMakeLists.txt <<EOF
cmake_minimum_required(VERSION 3.16)
project(bug C)
find_package(OpenMP REQUIRED)
EOF
$ mkdir build:it
$ cd build:it
$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- Check f...Minimal reproducer:
```
$ cat >CMakeLists.txt <<EOF
cmake_minimum_required(VERSION 3.16)
project(bug C)
find_package(OpenMP REQUIRED)
EOF
$ mkdir build:it
$ cd build:it
$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.16/Modules/FindOpenMP.cmake:511 (find_package_handle_standard_args)
CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/arekfu/src/foo/build:it/CMakeFiles/CMakeOutput.log".
See also "/home/arekfu/src/foo/build:it/CMakeFiles/CMakeError.log".
```
Seen on CMake v3.16. CMake works fine if the build directory does not contain any colon characters.https://gitlab.kitware.com/cmake/cmake/-/issues/20329add_custom_command with IMPLICIT_DEPENDS fails when implicitly dependent file...2020-02-15T16:55:58-05:00David Rohradd_custom_command with IMPLICIT_DEPENDS fails when implicitly dependent file is deletedThis [testcase.tar.gz](/uploads/64407df82065a25ac7f99600e84ab54b/testcase.tar.gz) shows a simple example of using a custom command for creating a source file and using IMPLICIT_DEPENDS for creating its dependencies.
`test.h` depends on ...This [testcase.tar.gz](/uploads/64407df82065a25ac7f99600e84ab54b/testcase.tar.gz) shows a simple example of using a custom command for creating a source file and using IMPLICIT_DEPENDS for creating its dependencies.
`test.h` depends on `test2.h`, the "normal" cxx file `test.cxx` as well as the custom-made cxx file `custom.cxx` depend on `test.h`. IMPLICIT_DEPENDS correctly creates the implicit dependency of `custom.cxx` on `test2.h`.
I can run cmake and compile it correctly (output below):
```
cmake $SRC_DIR && make
-- The C compiler identification is GNU 9.2.0
[...]
-- Build files have been written to: /home/qon/tmp3/build
[ 25%] Generating custom.cxx
Scanning dependencies of target foo
[ 50%] Building CXX object CMakeFiles/foo.dir/test.cxx.o
[ 75%] Building CXX object CMakeFiles/foo.dir/custom.cxx.o
[100%] Linking CXX executable foo
[100%] Built target foo
```
Now, when I change test.2 and rerun make, both cxx files are recompiled correctly (so far, the IMPLICIT_DEPENDS works)
```
touch $SRC_DIR/test2.h && make
[ 25%] Generating custom.cxx
Scanning dependencies of target foo
[ 50%] Building CXX object CMakeFiles/foo.dir/test.cxx.o
[ 75%] Building CXX object CMakeFiles/foo.dir/custom.cxx.o
[100%] Linking CXX executable foo
[100%] Built target foo
```
The problem is now: when I remove `test2.h`, and remove its include in test.h, the dependency resolution would need to see that `test.h` no longer depends on `test2.h`, and thus remove the dependency on `test2.h` from both `test.cxx` and `custom.cxx`. This works correctly for the normal `test.cxx` but fails for the IMPLICIT_DEPENDS:
```
rm $SRC_DIR/test2.h && echo "#foo" > $SRC_DIR/test.h && make
make[2]: *** No rule to make target '../test2.h', needed by 'custom.cxx'. Stop.
make[1]: *** [CMakeFiles/Makefile2:75: CMakeFiles/foo.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
```
`custom.cxx` has a hard dependency on `test2.h` in `CMakeFiles/foo.dir/depend.make`:
```
custom.cxx: ../test2.h
```
When I modify `CMakeFiles/foo.dir/depend.make` manually and remove this line, I can run make again, and it resolves the dependencies correctly:
```
make
Scanning dependencies of target foo
[ 25%] Building CXX object CMakeFiles/foo.dir/test.cxx.o
[ 50%] Generating custom.cxx
[ 75%] Building CXX object CMakeFiles/foo.dir/custom.cxx.o
[100%] Linking CXX executable foo
[100%] Built target foo
```
So in summary: if a file which is used as an implicit dependency from IMPLICIT_DEPENDS is deleted, it breaks the compilation also if it is no longer a dependency. (This problem does not appear for "normal" source files like `test.cpp`.) Instead, in this case IMPLICIT_DEPENDS should first rescan the dependencies to check if the file is still needed.https://gitlab.kitware.com/cmake/cmake/-/issues/20311Makefiles: clean a target, make this more user friendly2022-01-24T07:28:20-05:00Lieven de CockMakefiles: clean a target, make this more user friendlyas discussed on : https://discourse.cmake.org/t/makefiles-clean-a-target-make-this-more-user-friendly/427
Use case:
say a repository considered as 1 project
many libraries
many programs (as a result of combining functionali...as discussed on : https://discourse.cmake.org/t/makefiles-clean-a-target-make-this-more-user-friendly/427
Use case:
say a repository considered as 1 project
many libraries
many programs (as a result of combining functionality out of many of those libraries)
From the top of the buil directory for example we can build many of the targets (executables, libraries) and their dependencies. Say we have somewhere library/target “Foo”.
The we can do:
make Foo
make Foo/fast
make clean
==>the later cleans the entire project
Now what if I would want to clean only library/target Foo.
One way I know on how to do that is cd-ing into the directory in the build tree corresponding to that library, and there I can issues “make clean” which is then restricted to just cleaning the library Foo (it just clean the local library), one can also do at that location “make clean/fast”. I have no idea what the difference is.
Now cd-ing to this location is not that user friendly, but one important thing is, that it is indeed possible to clean just the library.
I would like/propose that we could do the following at the top level of the build directory:
make Foo/clean
So kind of mimicking the fast ‘thing’.
So 2 axes to this proposal:
ability to clean the library/target from the top
syntax proposal “/clean”https://gitlab.kitware.com/cmake/cmake/-/issues/20240Makefiles: Display target name between progress and echo output2020-01-22T21:11:56-05:00liaoyuan1011Makefiles: Display target name between progress and echo outputIn some cases, need to track target compiling details. Prints like '[ 68%] Building CXX object Source/xxx.cxx.o' can't reflect the target name directly. Especially when multiple tasks are executed in parallel, the output of messages is o...In some cases, need to track target compiling details. Prints like '[ 68%] Building CXX object Source/xxx.cxx.o' can't reflect the target name directly. Especially when multiple tasks are executed in parallel, the output of messages is out of order, and it is more difficult to correspond to the target name one by one.
So need a feature that display current target name between progress and subsequent output.
For example:
Original output:`[ 68%] Building CXX object Source/xxx.cxx.o`
Modified output:`[ 68%] [Target] Building CXX object Source/xxx.cxx.o`
https://gitlab.kitware.com/cmake/cmake/-/issues/20067UseSwig (expired) regression with the Make-based generators2020-06-01T09:35:29-04:00Ben BoeckelUseSwig (expired) regression with the Make-based generatorsWhen using a Make-based generator, the output files from `UseSwig` functions could no longer be used as a `DEPENDS` list in another `add_custom_command`. This is due to commit 2ee10119eac2802a234543581b1303d91b944afa (introduced in !1457...When using a Make-based generator, the output files from `UseSwig` functions could no longer be used as a `DEPENDS` list in another `add_custom_command`. This is due to commit 2ee10119eac2802a234543581b1303d91b944afa (introduced in !1457 in response to #17433). There's an obvious issue that I pointed out in https://gitlab.kitware.com/cmake/cmake/merge_requests/1457/diffs#note_662057.
There is a workaround to use the timestamp in the `DEPENDS` list I mention in the triage notes linked below, but this needs documentation to mention the issue at least for %"3.17.0" (and probably %"3.16.1" too while we're at it).
Main issue report: https://github.com/boatbod/op25/issues/25
My triage notes: https://github.com/boatbod/op25/issues/25#issuecomment-561439292
Discourse notice: https://discourse.cmake.org/t/newer-cmake-v-3-12-4-v-op25-project/320
While this is technically a ~"triage:regression", it was broken 2 years ago in 3.11, so I'm not labeling this issue as such.
Cc: @brad.king @felixschhttps://gitlab.kitware.com/cmake/cmake/-/issues/20027CMake generated Makefiles don't work when the "make" program resides in a dir...2019-11-26T09:58:49-05:00Ghost UserCMake generated Makefiles don't work when the "make" program resides in a directory containing spaces.The various Makefiles generated by CMake (version 3.15.3) frequently make use of the `$(MAKE)` variable to call into the `make` program. For example, in the main Makefile, the generated main `all` target looks like this:
```
# The main ...The various Makefiles generated by CMake (version 3.15.3) frequently make use of the `$(MAKE)` variable to call into the `make` program. For example, in the main Makefile, the generated main `all` target looks like this:
```
# The main all target
all: cmake_check_build_system
$(CMAKE_COMMAND) -E cmake_progress_start "/path/to/CMakeFiles" "/path/to/CMakeFiles/progress.marks"
$(MAKE) -f CMakeFiles/Makefile2 all
$(CMAKE_COMMAND) -E cmake_progress_start "/path/to/CMakeFiles" 0
.PHONY : all
```
When the path to the `make` program contains spaces (e.g., when using custom toolchains), these calls seem to not be properly quoted when `$(MAKE)` is invoked, leading to errors as the program is not found. This can be visualized by setting `CMAKE_VERBOSE_MAKEFILE` to `1`. Note that `$(CMAKE_COMMAND)` invocations are handled correctly, it is only the `$(MAKE)` invocations that lack quotes.
In this particular example, by quoting `$(MAKE)`, as in `"$(MAKE)" -f CMakeFiles/Makefile2 all`, the `make` step succeeds, but compilation fails shortly after as `$(MAKE)` is used in quite a few places.https://gitlab.kitware.com/cmake/cmake/-/issues/19586Fortran/Makefiles: Some preprocessor patterns break dependency scanning2021-06-10T09:07:18-04:00James FoucarFortran/Makefiles: Some preprocessor patterns break dependency scanningI wrote a simple reproducer program; it can be acquired here:
https://github.com/jgfouca/f90_dep_bug
The broken file contains:
```
module ice_flux
implicit none
save
real, dimension (1,2,3) :: &
daidtd , &
dvidtd...I wrote a simple reproducer program; it can be acquired here:
https://github.com/jgfouca/f90_dep_bug
The broken file contains:
```
module ice_flux
implicit none
save
real, dimension (1,2,3) :: &
daidtd , &
dvidtd
! The presence of this segment breaks the detection of the ice_state dependency
real, dimension(1,2,3) :: &
#ifdef FOO
baz, &
#endif
#ifdef BAR
bla, &
#endif
goo
! end broken segment
contains
subroutine init_history_dyn
use ice_state, only: aice, vice
daidtd (:,:,:) = aice(:,:,:)
dvidtd (:,:,:) = vice(:,:,:)
end subroutine init_history_dyn
end module ice_flux
```
With this code, the dependency on ice_state is missed. If either (or both) of the FOO or BAR ifdefs are removed, the dependency is found. If the 'use ice_state' statement is moved to before the ifdefs, the dependency is found.
This issue looks somewhat similar to #18188 but is a bit different since the ifdefs are removed from the use statement.