CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-07-17T06:56:31-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17820Visual Studio compiler detection fails because of spacebar in username2018-07-17T06:56:31-04:00MSleepyPandaVisual Studio compiler detection fails because of spacebar in usernameMy username contains a spacebar ("Forename Lastname", autogenerated by windows). For inspection, press ctrl+f and search for C:\Users\Forename with highlighting enabled. You'll find partial/incomplete versions of the username string.
``...My username contains a spacebar ("Forename Lastname", autogenerated by windows). For inspection, press ctrl+f and search for C:\Users\Forename with highlighting enabled. You'll find partial/incomplete versions of the username string.
```
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX86\x64\CL.exe /c /IC:\Users\Forename /Zi /nologo /W1 /WX- /diagnostics:classic /Od /Ob0 /D GIT_SSH /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_258f1.dir\Debug\\" /Fd"cmTC_258f1.dir\Debug\vc141.pdb" /Gd /TC /FC /errorReport:queue /GL- Lastname\Documents\Projekte\cratestats\target\debug\build\libssh2-sys-65d75e3acd4f00db\out/include "C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\testCCompiler.c"
include
c1 : fatal error C1083: Datei (Quelle) kann nicht geöffnet werden: "Lastname\Documents\Projekte\cratestats\target\debug\build\libssh2-sys-65d75e3acd4f00db\out/include": No such file or directory [C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj]
testCCompiler.c
Code wird generiert...
Die Erstellung des Projekts "C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER.
Fehler beim Buildvorgang.
"C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj" (Standardziel) (1) ->
(ClCompile Ziel) ->
c1 : fatal error C1083: Datei (Quelle) kann nicht geöffnet werden: "Lastname\Documents\Projekte\cratestats\target\debug\build\libssh2-sys-65d75e3acd4f00db\out/include": No such file or directory [C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj]
```
Resulting in visual studio compiler to be detected as broken
```
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.13.26128/bin/Hostx86/x64/cl.exe -- broken```https://gitlab.kitware.com/cmake/cmake/-/issues/17818add_custom_command results in bogus dependency loop2018-03-12T10:14:53-04:00phmaadd_custom_command results in bogus dependency loopThe repo is https://github.com/phma/quadlods and the commit is "Attempt to make primes.dat a target".
I need to install primes.dat, which is made by running "quadlods sortprimes", in what will be /usr/share/quadlods/ when it's packaged....The repo is https://github.com/phma/quadlods and the commit is "Attempt to make primes.dat a target".
I need to install primes.dat, which is made by running "quadlods sortprimes", in what will be /usr/share/quadlods/ when it's packaged. I added the line
```
add_custom_command(OUTPUT primes.dat COMMAND quadlods ARGS sortprimes MAIN_DEPENDENCY quadlods)
```
to CMakeLists.txt and not only did it **not** make primes.dat when told to, which is written about elsewhere, it also produced a bogus dependency loop:
```
-- Configuring done
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
"quadlib1" of type SHARED_LIBRARY
depends on "quadlods" (strong)
"quadlods" of type EXECUTABLE
depends on "quadlib1" (weak)
At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries.
-- Build files have been written to: /home/phma/build/quadlods/dbg
Makefile:581: recipe for target 'cmake_check_build_system' failed
make: *** [cmake_check_build_system] Error 1
```
quadlods does depend on quadlib1, but the only things quadlib1 depends on are quadlods.cpp, which is a source file, and its include file quadlods.h.
The CMake version is 3.9.1, from the package in Artful Aardvark running on Intel Core I7.https://gitlab.kitware.com/cmake/cmake/-/issues/17812GoogleTest: gtest_discover_tests() cannot pass lists for property values2023-11-23T17:28:13-05:00Craig ScottGoogleTest: gtest_discover_tests() cannot pass lists for property valuesThe `PROPERTIES` keyword in the `gtest_discover_tests()` function of the GoogleTest module is intended to allow a project to define properties to be set on each discovered test. This only works, however, for single-valued properties. If ...The `PROPERTIES` keyword in the `gtest_discover_tests()` function of the GoogleTest module is intended to allow a project to define properties to be set on each discovered test. This only works, however, for single-valued properties. If a property requires a list value (which a number of them can), there does not appear to be a way to pass that through. Consider this example:
```cmake
gtest_discover_tests(myTarget PROPERTIES LABELS "one;two")
```
This eventually results in the following call in the generated `myTarget[1]_tests.cmake` file:
```cmake
set_tests_properties( mytests.someTestCase PROPERTIES ... LABELS one two)
```
I have been unable to find any combination of quoting which would allow the label list to be preserved.Matthew WoehlkeMatthew Woehlkehttps://gitlab.kitware.com/cmake/cmake/-/issues/17806Finding the wrong fortran compiler2019-08-15T11:44:09-04:00howffFinding the wrong fortran compilerThe system comes with a fortran compiler available as gfortan and f95 in /usr/bin.
Installing the RedHat Developer Toolset provides a newer version of gfortran in /opt/rh but it doesn't provide the f95 name.
The newer versions are placed...The system comes with a fortran compiler available as gfortan and f95 in /usr/bin.
Installing the RedHat Developer Toolset provides a newer version of gfortran in /opt/rh but it doesn't provide the f95 name.
The newer versions are placed at the front of the $PATH.
cmake bootstrap looks for f95 and finds it in /usr/bin but if it looked for gfortran it would find the newer version.
Surely if cmake is finding the new gcc and g++ then it should also use the new gfortran?https://gitlab.kitware.com/cmake/cmake/-/issues/17805How to let ios and macos targets in one project when generate Xcode2019-10-14T10:26:52-04:00ledaHow to let ios and macos targets in one project when generate XcodeXcode support this, but when cmake generate project every time, I have to choose ios or macos platform, can't both. is it impossible to make both in one project? How to do that. for I can't find solution in docs or google, so I came here.Xcode support this, but when cmake generate project every time, I have to choose ios or macos platform, can't both. is it impossible to make both in one project? How to do that. for I can't find solution in docs or google, so I came here.https://gitlab.kitware.com/cmake/cmake/-/issues/17803Request: Add generator for Visual Studio 2017 Mac2018-03-27T10:41:43-04:00Robert BielikRequest: Add generator for Visual Studio 2017 MacI'm not sure if VS 2017 for Mac can read Xcode projects directly, but if not, a new generator for CMake is required.
https://www.visualstudio.com/vs/visual-studio-mac/I'm not sure if VS 2017 for Mac can read Xcode projects directly, but if not, a new generator for CMake is required.
https://www.visualstudio.com/vs/visual-studio-mac/https://gitlab.kitware.com/cmake/cmake/-/issues/17800CMAKE_CROSSCOMPILING_EMULATOR for cross-compilation being ignored with genera...2018-03-07T08:19:13-05:00Bradley GambleCMAKE_CROSSCOMPILING_EMULATOR for cross-compilation being ignored with generator expressionsI have a project that cross-compiles binaries from a Linux host to a Windows target using the MinGW compiler.
I have successfully been able to run these unit tests on my Linux host by setting the variable `CMAKE_CROSSCOMPILING_EMULATOR`...I have a project that cross-compiles binaries from a Linux host to a Windows target using the MinGW compiler.
I have successfully been able to run these unit tests on my Linux host by setting the variable `CMAKE_CROSSCOMPILING_EMULATOR` to 'wine64', so that the Windows .EXE files are invoked via Wine at CTest time.
This worked successfully with the following code:
``add_test(NAME hellotest
COMMAND helloworld)``
I then attempted to expand this to use generator expressions:
``add_test(NAME hellotest
COMMAND $<TARGET_FILE:helloworld>)``
At this point, the unit test will fail as it appears not to be invoked with `CMAKE_CROSSCOMPILING_EMULATOR` under MinGW.
Curiously, if I attempt to run the same example but with normal GCC and `CMAKE_SYSTEM_NAME` of `Linux`, it will detect the `CMAKE_CROSSCOMPILING_EMULATOR` variable successfully.
Therefore, `CMAKE_CROSSCOMPILING_EMULATOR` is only being ignored when `CMAKE_SYSTEM_NAME` is `Windows` AND generator expressions are used on tests.
A complete example is attached:
[* CMakeLists.txt](/uploads/d6fc971e7028e84cf3a6a7d3aa764919/CMakeLists.txt)
[* helloworld.c](/uploads/e1a55ff412f8a160e48f2740557d144f/helloworld.c)
If I run the following command:
`CC=cc CXX=c++ cmake ../ && cmake --build . && ctest .`
This command will succeed without error.
Conversely, if I invoke the command with MinGW targetting Windows, the generator command will fail:
`CC=x86_64-w64-mingw32-gcc-posix CXX=x86_64-w64-mingw32-g++-posix cmake .. -DMINGW=1 && cmake --build . && ctest .`
This command will only fail on the generator test. Looking in to LastTest.log it is clear that `CMAKE_CROSSCOMPILING_EMULATOR` is not being prepended and instead CTest is attempting to execute the binary directly.
As far as I can tell, generator expressions in `add_test` should not interfere with `CMAKE_CROSSCOMPILING_EMULATOR`, which should be prepended to all instances of `add_test` regardless.https://gitlab.kitware.com/cmake/cmake/-/issues/17799FindGTest.cmake wrongly reports that it does not find the libraries in Debug2020-11-20T12:10:23-05:00Olivier ComasFindGTest.cmake wrongly reports that it does not find the libraries in Debug**Problem:** CMake does not find GTest when I build in Debug
**Context:** I'm using the master version of GoogleTest (cloned yesterday) as the latest release (1.8.0) does not compile with the 15.5 update of Visual Studio. I realised tha...**Problem:** CMake does not find GTest when I build in Debug
**Context:** I'm using the master version of GoogleTest (cloned yesterday) as the latest release (1.8.0) does not compile with the 15.5 update of Visual Studio. I realised that previously when I compiled googletest-1.8.0 in Debug, the names of the libraries were gtest.lib and gtest_main.lib. With the latest version, a 'd' suffix has been added leading to gtestd.lib and gtest_maind.lib.
**What's wrong:** In FindGTest.cmake (version 3.10.2), the names with a 'd' suffix have been taken into account:
`__gtest_find_library(GTEST_LIBRARY gtest)
__gtest_find_library(GTEST_LIBRARY_DEBUG gtestd)
__gtest_find_library(GTEST_MAIN_LIBRARY gtest_main)
__gtest_find_library(GTEST_MAIN_LIBRARY_DEBUG gtest_maind)`
But then we required both GTEST_LIBRARY and GTEST_MAIN_LIBRARY to be found even in Debug:
`FIND_PACKAGE_HANDLE_STANDARD_ARGS(GTest DEFAULT_MSG GTEST_LIBRARY GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY)`
So if googletest was compiled in debug, GTEST_LIBRARY_DEBUG is set correctly but CMake reports that it cannot find GTest anyway because FindGTest.cmake requires GTEST_LIBRARY and GTEST_MAIN_LIBRARY to be set. But if we have a Debug build, it is perfectly normal that GTEST_LIBRARY and GTEST_MAIN_LIBRARY are not set.
**CMake error:**
> CMake Error at [...]/CMake-3.10.2/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find GTest (missing: GTEST_LIBRARY GTEST_MAIN_LIBRARY) (Required is at least version "1.8.0")https://gitlab.kitware.com/cmake/cmake/-/issues/17798Eclipse [Source directory] virtual link always points to C: even when project...2018-03-07T07:59:25-05:00SNiLDEclipse [Source directory] virtual link always points to C: even when project is on D:> CMake version 3.10.2
> Operating system: Windows 10 64-bit
> Compiler: Visual Studio 2017 Express with Ninja
> IDE: Eclipse Oxygen.2 Release (4.7.2) Build id: 20171218-0600
Steps to reproduce:
1. Make project directory on D: drive...> CMake version 3.10.2
> Operating system: Windows 10 64-bit
> Compiler: Visual Studio 2017 Express with Ninja
> IDE: Eclipse Oxygen.2 Release (4.7.2) Build id: 20171218-0600
Steps to reproduce:
1. Make project directory on D: drive and make simple CMakeLists.txt
2. Generate Eclipse CDT project with following command `cmake -G"Eclipse CDT4 - Ninja" -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_ECLIPSE_VERSION=4.7 -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j8 ..\project`
3. Import project to Eclipse with Import -> Existing Projects into Workspace
Now take properties of *[Source directory]* virtual link and see that the Location field says `C:\projects - (does not exist)`.
If you manually change this to point to `D:\projects` it will work normally. After this if you change any CMakeLists.txt it will cause the project to be recreated and the virtual link will again point to `C:\projects - (does not exist)`.https://gitlab.kitware.com/cmake/cmake/-/issues/17795Building a Swift only .app bundle doesn't add rpath (mixed Swift/C works)2018-03-06T13:08:08-05:00Harry MallonBuilding a Swift only .app bundle doesn't add rpath (mixed Swift/C works)I sent an email to the mailing list but I think I explained myself badly.
We are building an .app bundle on Xcode with Swift sources (and trying to use CMake). Swift sources require a shared library which Xcode helpfully puts in the .ap...I sent an email to the mailing list but I think I explained myself badly.
We are building an .app bundle on Xcode with Swift sources (and trying to use CMake). Swift sources require a shared library which Xcode helpfully puts in the .app for you. Our CMakeLists looks somthing like this (shortened significantly):
```
enable_language(Swift)
set(CMAKE_Swift_LANGUAGE_VERSION 4.0)
set(sourceFiles
AboutWindow.swift
AppDelegate.swift
Device.swift
DeviceMenuController.swift
# test.c
)
add_executable(hardwareui
MACOSX_BUNDLE
${sourceFiles}
)
set_target_properties(hardwareui PROPERTIES
INSTALL_RPATH "@loader_path/../Frameworks"
BUILD_RPATH "@loader_path/../Frameworks"
)
```
If I debug cmake while making the Xcode project I can see that `this->RuntimeFlag` in `cmComputeLinkInformation::cmComputeLinkInformation` is false. This means that the rpath is not added and then the program doesn't run. If I add in the test.c file (commented out above) then `this->LinkLanguage` is different so `this->RuntimeFlag` is set and everything works. I am not really sure of the best way to fix this.https://gitlab.kitware.com/cmake/cmake/-/issues/17791MAKEFLAGS breaks C++11 feature check during bootstrap2018-03-05T16:58:29-05:00David FaureMAKEFLAGS breaks C++11 feature check during bootstrap`export MAKEFLAGS=-j8` breaks cmake's bootstrap, which says
```
-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
```
Yes...`export MAKEFLAGS=-j8` breaks cmake's bootstrap, which says
```
-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
```
Yes this looks completely unrelated, hold on, it will make sense.
The actual output from the try_compile is
```
Run Build Command:"/home/dfaure/bin/gmake" "cmTC_60a44/fast"
gmake -f CMakeFiles/cmTC_60a44.dir/build.make CMakeFiles/cmTC_60a44.dir/build
gmake[1]: warning: -jN forced in submake: disabling jobserver mode.
gmake[1]: Entering directory '/d/kde/build/5/cmake-git/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_60a44.dir/cm_cxx_unique_ptr.cxx.o
/home/dfaure/bin/g++ -std=gnu++1z -o CMakeFiles/cmTC_60a44.dir/cm_cxx_unique_ptr.cxx.o -c /d/kde/src/5/cmake-git/Source/Checks/cm_cxx_unique_ptr.cxx
Linking CXX executable cmTC_60a44
/d/kde/build/5/cmake-git/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTC_60a44.dir/link.txt --verbose=1
/home/dfaure/bin/g++ -rdynamic CMakeFiles/cmTC_60a44.dir/cm_cxx_unique_ptr.cxx.o -o cmTC_60a44
gmake[1]: Leaving directory '/d/kde/build/5/cmake-git/CMakeFiles/CMakeTmp'
```
Notice how the third line has a gmake warning (due to `gmake -f` being called instead of `$(MAKE) -f`).
This triggers the following code in Source/Checks/cm_cxx_features.cmake:
```
# If using the feature causes warnings, treat it as broken/unavailable.
if(check_output MATCHES "[Ww]arning")
set(CMake_HAVE_CXX_${FEATURE} OFF CACHE INTERNAL "TRY_COMPILE" FORCE)
endif()
```
So the make warning is treated as a compiler warning ;-)
I've been trying to find the "proper" fix for this ($(MAKE) instead of gmake), but I can't find where that comes from.
Source/cmLocalUnixMakefileGenerator3.cxx does say $(MAKE)...
Version: cmake git, release branch. git describe says `v3.11.0-rc2`.https://gitlab.kitware.com/cmake/cmake/-/issues/17789CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION detects nothing in VS2015 on Win7 642018-04-14T09:09:41-04:00primaevalCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION detects nothing in VS2015 on Win7 64The Windows SDK detection logic won't find the installed Windows SDK.
The current logic is probably described here according to Google.
`https://gitlab.kitware.com/cmake/cmake/commit/3f077996f58ca905125fc2387614b24c68c6f09e`
The registr...The Windows SDK detection logic won't find the installed Windows SDK.
The current logic is probably described here according to Google.
`https://gitlab.kitware.com/cmake/cmake/commit/3f077996f58ca905125fc2387614b24c68c6f09e`
The registry entries seem to be different than what the code is looking for.
There is an extra key section at
```
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots\10.0.16299.0]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots\10.0.16299.0\Installed Options]
"OptionId.WindowsSoftwareLogoToolkit"=dword:00000001
"OptionId.UWPManaged"=dword:00000001
"OptionId.AvrfExternal"=dword:00000001
"OptionId.UWPCPP"=dword:00000001
```
but nothing at
```
[HKEY_CURRENT_USER\Software\Microsoft\Windows Kits]
[HKEY_CURRENT_USER\Software\Microsoft\Windows Kits\CEIP]
"OptIn"=dword:00000001
```
I just did a fresh install of VS2015 on Win7 64bit with this version
```
Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
```
The installed sdks in
`C:\Program Files (x86)\Windows Kits\10\Include`
are
```
10.0.10150.0
10.0.10240.0
10.0.14393.0
10.0.16299.0
```https://gitlab.kitware.com/cmake/cmake/-/issues/17786find_package has different behaviours in config and module options2018-03-05T17:00:11-05:00Stefano Sinigardifind_package has different behaviours in config and module optionsI am experiencing different behaviours of `find_package()` calls, depending from the option it is going to use to obtain result variables. Suppose I am creating a library (A) which depends on other libraries (B and C) and I am building a...I am experiencing different behaviours of `find_package()` calls, depending from the option it is going to use to obtain result variables. Suppose I am creating a library (A) which depends on other libraries (B and C) and I am building all of them from source on my computer, using CMake to drive the building of all of them.
Let's suppose also that lib B has its own FindLibB.cmake module, while lib C exports a LibC-Config.cmake.
In my library A I will request a `find_package(LibB)` and a `find_package(LibC)` of course to be able to use them.
But then I see two different behaviours: the `LibA_LIBRARY` variable will contain the full path to the library and so the linker is perfectly satisfied for the project itself and also any downstream project, while the `LibC_LIBRARY` variable will contain only the name of the library. This will make my library A happy (since CMake will populate the library dir for my project), but will make any downstream project very unhappy because they will be unable to find the library if not instructed to do a `find_package(LibC)` (which should be not necessary if the downstream project does not have an explicit dependency on it).
An example: I built OpenCV on Windows, which depends on many libraries, some found through their cmake module file (example: LibLZMA), others through their cmake config file (example: VTK). OpenCV builds without any problem but if I try to use it in a downstream project, the linker complains that it does not know where to find VTK libraries, while it knows perfectly he had to link to LibLZMA which is found because it has the full path. Of course my downstream project is not triggering any `find_package(LibLZMA)` nor `find_package(VTK)`, just a `find_package(OpenCV)`. I could add a `find_package(VTK)` in my downstream project too, but I am sure there must be more elegant solutions!
I opened an [issue](https://github.com/opencv/opencv/issues/10977) on the OpenCV repository, for them it's a known issue with CMake, but maybe I am just unaware of any best practice here, so please let me know.https://gitlab.kitware.com/cmake/cmake/-/issues/17783Windows now has per-directory case sensitivity2018-03-05T16:57:43-05:00Ben BoeckelWindows now has per-directory case sensitivityNot sure how much this affects CMake on Windows, but [here's a blog post](https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/).Not sure how much this affects CMake on Windows, but [here's a blog post](https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/).https://gitlab.kitware.com/cmake/cmake/-/issues/17781gcc LTO / gnu make jobserver integration2022-12-09T04:17:43-05:00Todd Richmondgcc LTO / gnu make jobserver integrationgcc supports -flto=jobserver to ensure that parallel builds limit resources consistently under gnu make. However, CMake has no way to specify that (or to support -flto=x for x children)
In addition, the Makefile target line will need a ...gcc supports -flto=jobserver to ensure that parallel builds limit resources consistently under gnu make. However, CMake has no way to specify that (or to support -flto=x for x children)
In addition, the Makefile target line will need a + option so that jobserver details are passed to sub-makes. Otherwise gnu make will spew errors to the console about not working with jobserver mode that cannot be suppressed
#16808 is open for full customization but doesn't document the "+" requirement and is a bigger endeavorhttps://gitlab.kitware.com/cmake/cmake/-/issues/17773Document support for module definition files (.def) as source files2018-02-28T08:58:27-05:00Paweł WieczorekDocument support for module definition files (.def) as source filesI have a shared library which contains a source file with `.def` extension and it provokes cmake to generate rule (it is stored as PRE_LINK in `build.ninja`) executing `cmake -E __create_def`.
I spent some time to analyse cmake source ...I have a shared library which contains a source file with `.def` extension and it provokes cmake to generate rule (it is stored as PRE_LINK in `build.ninja`) executing `cmake -E __create_def`.
I spent some time to analyse cmake source files to discover that this rule is Windows-specific. It should be documented somewhere.
I guess that the def file should contain list of object files or symbol names to be exported. I think it would be more intuitive if it would NOT be passed as *source file*. I think it is counterintuitive that having source file ended with `.def` provokes such situation.
Maybe cmake should also generate error message that command is not working on user's platform. The error message that I used unknown command wasted a lot of my time since I though that rule was generated incorrectly (bad string concatenation or something).https://gitlab.kitware.com/cmake/cmake/-/issues/17772How to solve the Warning problem after the c# project references ZERO_CHECK p...2018-05-08T12:25:51-04:00luotyHow to solve the Warning problem after the c# project references ZERO_CHECK project?![ZeroCheck1](/uploads/66130341ecb7f1912c63253b15e6f36e/ZeroCheck1.png)![ZeroCheck2](/uploads/e0a6bef8f8fd7f395e9fb67f9bbe8df4/ZeroCheck2.png)![ZeroCheck1](/uploads/66130341ecb7f1912c63253b15e6f36e/ZeroCheck1.png)![ZeroCheck2](/uploads/e0a6bef8f8fd7f395e9fb67f9bbe8df4/ZeroCheck2.png)https://gitlab.kitware.com/cmake/cmake/-/issues/17771FindGDAL module populates GDAL_LIBRARY with the first dependent library, not ...2018-02-28T08:22:57-05:00Adam ThompsonFindGDAL module populates GDAL_LIBRARY with the first dependent library, not libgdal.a* RHEL 7.4
* CMake 3.9.0
* GDAL 2.1.1
My project has a dependency on `GDAL` and I'm attempting to use `find_package(GDAL ...)` to obtain the path to its library. The call succeeds, but `GDAL_LIBRARY` is populated with the first depe...* RHEL 7.4
* CMake 3.9.0
* GDAL 2.1.1
My project has a dependency on `GDAL` and I'm attempting to use `find_package(GDAL ...)` to obtain the path to its library. The call succeeds, but `GDAL_LIBRARY` is populated with the first dependent library, `/path/to/proj4/lib/libproj.a` in my case, instead of `/path/to/gdal/lib/libdal.a`.
I looked at [FindGDAL.cmake](https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindGDAL.cmake) to determine how `GDAL_LIBRARY` is being populated and it's trying to use `gdal-config` to get the library and its path. The output from this command would look something like this:
```
/path/to/gdal/lib/libgdal.a -L/path/to/proj4/lib -lproj -L/path/to/geos/lib -l:libgeos_c.a -l:libgeos.a -ljpeg -L/path/to/geotiff/lib -l:libgeotiff.a -lm -L/path/to/tiff/lib -ltiff -lpng -lz -lpthread -lm -lrt -ldl
```
Unfortunately, the logic on lines 70-73 appears to use the dependent libraries and their paths as hints to locate GDAL's library and populate `GDAL_LIBRARY`. In my case, this results in `GDAL_LIBRARY` being set to `/path/to/proj4/lib/libproj.a` instead of `/path/to/gdal/lib/libgdal.a`, the first entry in the output from `gdal-config`.https://gitlab.kitware.com/cmake/cmake/-/issues/17770[ExternalProject] GIT_SHALLOW is not shallow enough2023-03-16T21:27:38-04:00Sebastian Bøe[ExternalProject] GIT_SHALLOW is not shallow enoughHi,
the use-case of "GIT_SHALLOW 1" is to optimize the cloning to download as little as possible. But the ExternalProject_Add implementation does this:
```
if(NOT GIT_VERSION_STRING VERSION_LESS 1.7.10)
set(git_clone_shallow_opti...Hi,
the use-case of "GIT_SHALLOW 1" is to optimize the cloning to download as little as possible. But the ExternalProject_Add implementation does this:
```
if(NOT GIT_VERSION_STRING VERSION_LESS 1.7.10)
set(git_clone_shallow_options "--depth 1 --no-single-branch")
else()
set(git_clone_shallow_options "--depth 1")
endif()
```
For some git versions the **--no-single-branch** option is passed, and this option will cause all branch HEAD's to be downloaded, instead of just the branch/tag/commit that one wanted to download. This causes a performance problem if a branch exists purely to prune the master branch.
My question is:
Why is this option passed for some git --versions?
Is there a way we can support single-sha downloads with CMake?
Should the documentation be updated to reflect that GIT_SHALLOW does not just download a single revision?
CMake documentation:
GIT_SHALLOW <bool>
When this option is enabled, the ``git clone`` operation will be given
the ``--depth 1`` option. This performs a shallow clone, which avoids
downloading the whole history and instead **retrieves just the commit**
denoted by the ``GIT_TAG`` option.
git documentation:
> --depth <depth>
> Create a shallow clone with a history truncated to the
> specified number of commits. Implies --single-branch
> unless --no-single-branch is given to fetch the
> histories near the tips of all branches. If you want to
> clone submodules shallowly, also pass
> --shallow-submodules.
>
> --[no-]single-branch
> Clone only the history leading to the tip of a single
> branch, either specified by the --branch option or the
> primary branch remote’s HEAD points at. Further fetches
> into the resulting repository will only update the
> remote-tracking branch for the branch this option was
> used for the initial cloning. If the HEAD at the remote
> did not point at any branch when --single-branch clone
> was made, no remote-tracking branch is created.
>https://gitlab.kitware.com/cmake/cmake/-/issues/17767[CMake] [CTest] Using rerun-failed when tests pass the first time2020-06-24T23:53:29-04:00Ford[CMake] [CTest] Using rerun-failed when tests pass the first timeMy team is using CMake as our build system, and we're also using CTest for our unit tests. We wanted to speed up running tests by only running the tests that failed previously or when the binary file had changed. While trying to use `-...My team is using CMake as our build system, and we're also using CTest for our unit tests. We wanted to speed up running tests by only running the tests that failed previously or when the binary file had changed. While trying to use `--rerun-failed`, we noticed that all our tests were being run on subsequent ctest invocations, even though they had all passed on the previous step. After looking into it, we saw that the file `LastTestsFailed.log` was not being created. We tried making a simple
empty one, but that didn't change anything. We then changed one of our tests to fail, then tried running `ctest` with `--rerun-failed` again, and on the subsequent run it only re-ran that failed test. We reverted that test back to normal, and now `--rerun-failed` only runs that test, which makes sense based on the documentation.
Is this by design? We expected that if all our tests never failed on the first invocation, that subsequent runs would not cause those tests to re-run unless the binary had changed. The behaviour also seems inconsistent, since if you add an entry into an empty `LastTestsFailed.log` for a non-existant test, then subsequent test runs will not run any of your tests.
**Versions**:
- ctest version 3.7.2
- ctest version 3.10.1
**Steps to Reproduce**:
1. Create a basic project with one source file and two tests.
2. Build the project, and run `ctest --rerun-failed`, all tests should run.
3. Run again; all tests should run.
4. Add a failing line to one of the two tests.
5. Build and run `ctest --rerun-failed`; all tests should run.
6. Run 'ctest --rerun-failed' again; only the failing test should run.
7. Edit the `CMakeLists.txt` to remove the failing test definition.
8. Build and run `ctest --rerun-failed`; outputs: `No tests were found!!!`
**Expected Behaviour**:
1. If no `LastTestsFailed.log` exists, should create one; if no tests failed, then this file should be empty.
2. On subsequent runs, if a `LastTestsFailed.log` exists, but is empty, then no tests should be run.
Attached is a sample project demonstrating this behaviour: [example.zip](/uploads/259b2324283f8124522e8fd9d279c36f/example.zip)
Commenting/uncommenting the division test will show the issue.
```
/Users/ford/Downloads/example/build $ ctest --rerun-failed
Test project /Users/ford/Downloads/example/build
Start 1: addition
1/3 Test #1: addition ......................... Passed 0.00 sec
Start 2: subtraction
2/3 Test #2: subtraction ...................... Passed 0.00 sec
Start 3: multiplication
3/3 Test #3: multiplication ................... Passed 0.00 sec
100% tests passed, 0 tests failed out of 3
Total Test time (real) = 0.01 sec
/Users/ford/Downloads/example/build $ ctest --rerun-failed
Test project /Users/ford/Downloads/example/build
Start 1: addition
1/3 Test #1: addition ......................... Passed 0.00 sec
Start 2: subtraction
2/3 Test #2: subtraction ...................... Passed 0.00 sec
Start 3: multiplication
3/3 Test #3: multiplication ................... Passed 0.01 sec
100% tests passed, 0 tests failed out of 3
Total Test time (real) = 0.01 sec
```
**Adding in the division test**:
```
/Users/ford/Downloads/example/build $ make
[ 25%] Built target test-division
[ 50%] Built target test-addition
[ 75%] Built target test-multiplication
[100%] Built target test-subtraction
/Users/ford/Downloads/example/build $ ctest --rerun-failed
Test project /Users/ford/Downloads/example/build
Start 1: addition
1/4 Test #1: addition ......................... Passed 0.00 sec
Start 2: subtraction
2/4 Test #2: subtraction ...................... Passed 0.00 sec
Start 3: multiplication
3/4 Test #3: multiplication ................... Passed 0.00 sec
Start 4: division
4/4 Test #4: division .........................***Failed 0.00 sec
75% tests passed, 1 tests failed out of 4
Total Test time (real) = 0.02 sec
The following tests FAILED:
4 - division (Failed)
Errors while running CTest
/Users/ford/Downloads/example/build $ ctest --rerun-failed
Test project /Users/ford/Downloads/example/build
Start 4: division
1/1 Test #4: division .........................***Failed 0.00 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.01 sec
The following tests FAILED:
4 - division (Failed)
Errors while running CTest
```
**After commenting out the division test**:
```
/Users/ford/Downloads/example/build $ cmake ..
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/ford/Downloads/example/build
/Users/ford/Downloads/example/build $ make
[ 25%] Built target test-division
[ 50%] Built target test-addition
[ 75%] Built target test-multiplication
[100%] Built target test-subtraction
/Users/ford/Downloads/example/build $ ctest --rerun-failed
Test project /Users/ford/Downloads/example/build
No tests were found!!!
```