CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-04-03T23:02:56-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16717CPACK_RPM - CPACK_RPM_DEBUGINFO_PACKAGE - cmake-3.8.latest fails to generate ...2017-04-03T23:02:56-04:00Daniel BlackCPACK_RPM - CPACK_RPM_DEBUGINFO_PACKAGE - cmake-3.8.latest fails to generate debuginfo packages where 3.7.2 did```
cmake --version
cmake version 3.8.20170312-gce070
cmake ../mariadb-server/ -DRPM=fedora | tee /tmp/cmake-new-c.txt && make VERBOSE=1 -j32 --output-sync=target package
...
CMake Warning (dev) at /usr/local/cmake-3.8.20170312-g...```
cmake --version
cmake version 3.8.20170312-gce070
cmake ../mariadb-server/ -DRPM=fedora | tee /tmp/cmake-new-c.txt && make VERBOSE=1 -j32 --output-sync=target package
...
CMake Warning (dev) at /usr/local/cmake-3.8.20170312-gce070-Linux-x86_64/share/cmake-3.8/Modules/CPackRPM.cmake:2229 (message):
CPackRPM:Warning: debuginfo package was requested but will not be generated
as no source files were found! Component: 'test'.
...
ls *rpm
MariaDB-5.5.55-fedora-x86_64-common.rpm MariaDB-5.5.55-fedora-x86_64-shared.rpm MariaDB-server-5.5.55-1.fc25.x86_64.rpm
MariaDB-5.5.55-fedora-x86_64-devel.rpm MariaDB-client-5.5.55-1.fc25.x86_64.rpm MariaDB-test-5.5.55-1.fc25.x86_64.rpm
```
from: https://github.com/grooverdan/mariadb-server/tree/5.5-MDEV-4646-rpm-debug-symbols
[build-new-c.txt](/uploads/34204ba28dc8b5e88ac87811c650ccad/build-new-c.txt)3.8.0Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16711New CSharpUtilities module documentation is incorrect2023-12-08T15:20:22-05:00Don BiglerNew CSharpUtilities module documentation is incorrectNoticed a copy and paste error in the documentation for the new CSharpUtilities module in CMake 3.8.0-rc2:
https://cmake.org/cmake/help/v3.8/module/CSharpUtilities.html#module:CSharpUtilities
The documentation for csharp_set_designer_c...Noticed a copy and paste error in the documentation for the new CSharpUtilities module in CMake 3.8.0-rc2:
https://cmake.org/cmake/help/v3.8/module/CSharpUtilities.html#module:CSharpUtilities
The documentation for csharp_set_designer_cs_properties should be something other than "Sets source file properties for use of WPF/XAML. Use this, if your CSharp target uses WPF/XAML" as that text belongs to csharp_set_xaml_cs_properties.3.8.0Michael StürmerMichael Stürmerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16710cmake tests fail with new rpm2017-05-03T19:30:24-04:00Orion Poplawskicmake tests fail with new rpmOn Fri, 2017-03-10 at 11:51 -0700, Orion Poplawski wrote:
> A cmake build test is failing with the jump in rpm from 4.13.0.1-3.fc26 >
> 4.13.0.1-7.fc27
>
> The upshot appears to be that an rpm generated by cmake's cpack utility has
> ad...On Fri, 2017-03-10 at 11:51 -0700, Orion Poplawski wrote:
> A cmake build test is failing with the jump in rpm from 4.13.0.1-3.fc26 >
> 4.13.0.1-7.fc27
>
> The upshot appears to be that an rpm generated by cmake's cpack utility has
> additional files in it, e.g.:
>
> /usr/lib/.build-id
> /usr/lib/.build-id/5d
> /usr/lib/.build-id/5d/a319a6e633c6da1cd98aafe3744adf664d529a
>
> are these to be expected, or are these supposed to be elsewhere?
Good you have a sanity check for this. But those are (now) expected to
be there. This is because of the new default setting of the
_build_id_links macro (compat):
```
# Defines how and if build_id links are generated for ELF files.
# The following settings are supported:
#
# - none
# No build_id links are generated.
#
# - alldebug
# build_id links are generated only when the __debug_package global is
# defined. This will generate build_id links in the -debuginfo package
# for both the main file as /usr/lib/debug/.build-id/xx/yyy and for
# the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
# This is the old style build_id links as generated by the original
# find-debuginfo.sh script.
#
# - separate
# build_id links are generate for all binary packages. If this is a
# main package (the __debug_package global isn't set) then the
# build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is
# a -debuginfo package (the __debug_package global is set) then the
# build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
#
# - compat
# Same as for "separate" but if the __debug_package global is set then
# the -debuginfo package will have a compatibility link for the main
# ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
%_build_id_links compat
```
For more background see also:
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
Specifically this breaks CPackComponentsForAll-RPM-IgnoreGroup and RunCMake.CPack_RPM. See http://kojipkgs.fedoraproject.org/work/tasks/5505/18305505/build.log for full build log.3.8.0Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16706CMake prefers git.exe installed by VS20172024-01-03T15:12:19-05:00Mateusz ŁoskotCMake prefers git.exe installed by VS2017I just submitted issue report to Visual Studio 2017:
https://developercommunity.visualstudio.com/content/problem/26539/vs2017-deployed-gitexe-not-usable.html
I am, however, not clear where might be the problem, so I'm also letting the C...I just submitted issue report to Visual Studio 2017:
https://developercommunity.visualstudio.com/content/problem/26539/vs2017-deployed-gitexe-not-usable.html
I am, however, not clear where might be the problem, so I'm also letting the CMake Team know about the problem here.
------
## Environment
* Windows 10
* Visual Studio Professional 2017 (Version 15.0.26228.4)
* Git 2.11.1.windows.1 (`C:\Program Files\Git\cmd\git.EXE` in `PATH`)
## Problem
I have a project, https://github.com/lexicalunit/nanodbc/, with `CMakeLists.txt` which calls `git` to add external project:
```
find_package(Git REQUIRED)
ExternalProject_Add(
catch
PREFIX ${CMAKE_BINARY_DIR}/catch
GIT_REPOSITORY https://github.com/philsquared/Catch.git
UPDATE_COMMAND ${GIT_EXECUTABLE} pull
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
LOG_DOWNLOAD ON)
```
In Visual Studio 2017 command prompt, I run CMake to configure the build and CMake generates custom build step file `catch-gitclone.cmake`.
CMake seems to prefer `git.exe` from the VS2017 installation instead of the one available in `PATH`
```
execute_process(
COMMAND "C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer/Git/cmd/git.exe" ${git_options} checkout master --
WORKING_DIRECTORY "D:/dev/nanodbc/_build32/catch/src/catch"
RESULT_VARIABLE error_code
)
```
The problem is, that `C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer/Git/cmd/git.exe` seems not directly usable (either a bug or by design, who knows) and the `git clone` terminates with System Error prompts about missing DLLs: libintl-8.dll, , libcurl-4.dll, libpcre-1.dll, libssp-0.dll
![cmake-3.8rc2-vs2017-run-git-dll-hell](/uploads/7175c29ae2180350fe32cd70bd289834/cmake-3.8rc2-vs2017-run-git-dll-hell.png)
Perhaps it is something that could be corrected, so CMake prefers `C:\Program Files\Git\cmd\git.EXE` which is available in the `PATH`.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16697cmake crashes when using CSharp when there's a custom target to build a C# pr...2017-05-03T19:30:24-04:00Martin Gegenheimercmake crashes when using CSharp when there's a custom target to build a C# projectcmake 3.8.0-rc2:
Trying to use the new C# support. I have a custom target to build a C# project with msbuild.
CSharp enabled in project() and a C# target added:
cmake crashes (null ptr) in cmVisualStudio10TargetGenerator::WriteMSToolConf...cmake 3.8.0-rc2:
Trying to use the new C# support. I have a custom target to build a C# project with msbuild.
CSharp enabled in project() and a C# target added:
cmake crashes (null ptr) in cmVisualStudio10TargetGenerator::WriteMSToolConfigurationValuesManaged() because ClOptions["Debug"] == null for the custom target.
cmake.exe!cmVisualStudioGeneratorOptions::IsDebug() Line 133 C++
cmake.exe!cmVisualStudio10TargetGenerator::WriteMSToolConfigurationValuesManaged(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & config) Line 979 C++
cmake.exe!cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues() Line 912 C++
cmake.exe!cmVisualStudio10TargetGenerator::Generate() Line 449 C++
cmake.exe!cmLocalVisualStudio10Generator::Generate() Line 76 C++
cmake.exe!cmGlobalGenerator::Generate() Line 1321 C++
cmake.exe!cmGlobalVisualStudio7Generator::Generate() Line 291 C++
cmake.exe!cmGlobalVisualStudio10Generator::Generate() Line 326 C++
cmake.exe!cmake::Generate() Line 1625 C++3.8.0Michael StürmerMichael Stürmerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16693FindHDF5: HDF5_DEFINITIONS can be incorrect2017-05-03T19:30:25-04:00Kris ThielemansFindHDF5: HDF5_DEFINITIONS can be incorrectWhen using _HDF5_parse_compile_line, HDF5_C_DEFINITIONS etc are set without the -D option. On my Lubuntu version 15.10 this leads it to be set to
> _LARGEFILE64_SOURCE;_LARGEFILE_SOURCE;_FORTIFY_SOURCE=2
This then causes a compilation...When using _HDF5_parse_compile_line, HDF5_C_DEFINITIONS etc are set without the -D option. On my Lubuntu version 15.10 this leads it to be set to
> _LARGEFILE64_SOURCE;_LARGEFILE_SOURCE;_FORTIFY_SOURCE=2
This then causes a compilation problem when using
> add_definitions(${HDF5_DEFINITIONS})
I can fix this by adjusting FindHDF5.cmake L361 to include the -D flag, i.e.
old:
```
elseif("${arg}" MATCHES "^-D(.*)$")
# compile definition
list(APPEND ${definitions} "-D${CMAKE_MATCH_1}"
```
fixed:
```
elseif("${arg}" MATCHES "^-D(.*)$")
# compile definition
list(APPEND ${definitions} "-D${CMAKE_MATCH_1}")
```3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16687find_library: Skip 'lib => lib<arch>' searches if one symlinks the other2017-05-04T16:23:48-04:00Brad Kingfind_library: Skip 'lib => lib<arch>' searches if one symlinks the otherThe [FIND_LIBRARY_USE_LIB32_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.html)and [FIND_LIBRARY_USE_LIB64_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS.html) global prope...The [FIND_LIBRARY_USE_LIB32_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.html)and [FIND_LIBRARY_USE_LIB64_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS.html) global properties ask [find_library](https://cmake.org/cmake/help/v3.8/command/find_library.html) to look in `lib<arch>` directories automatically before corresponding `lib` directories. However, if `lib<arch>` is just a symlink to `lib` (or vice-versa) then we should skip adding the `lib<arch>` path.
This is important to avoid finding paths that are unnecessarily suffixed with `<arch>` because the symlinks typically exist only to satisfy other software that expects them.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16682RPATH exclusion of implicit directories does not consider symlinks2017-05-04T16:23:48-04:00Brad KingRPATH exclusion of implicit directories does not consider symlinksWhen computing the runtime search path to pass to the linker `-rpath` option we automatically filter out directories that are implied by the platform or toolchain. This avoids unnecessary rpath entries that may conflict with the real dy...When computing the runtime search path to pass to the linker `-rpath` option we automatically filter out directories that are implied by the platform or toolchain. This avoids unnecessary rpath entries that may conflict with the real dynamic loader's paths.
However, the filter does not account for differences in directory names due to symbolic links. This can cause undesired rpath entries to be left behind.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16654FTFBS due to FindGTK22017-05-04T16:23:48-04:00OzkanFTFBS due to FindGTK2```
$ ../cmake-3.8.0-rc1/configure --prefix=$(HOME)/x1
[...]
-- Performing Test run_pic_test
-- Performing Test run_pic_test - Success
-- Performing Test run_inlines_hidden_test
-- Performing Test run_inlines_hidden_test - Success
CMake ...```
$ ../cmake-3.8.0-rc1/configure --prefix=$(HOME)/x1
[...]
-- Performing Test run_pic_test
-- Performing Test run_pic_test - Success
-- Performing Test run_inlines_hidden_test
-- Performing Test run_inlines_hidden_test - Success
CMake Error at Modules/FindGTK2.cmake:226 (message):
Include file does not exist
Call Stack (most recent call first):
Modules/FindGTK2.cmake:767 (_GTK2_SIGCXX_GET_VERSION)
Tests/FindGTK2/CMakeLists.txt:1 (find_package)
-- Configuring incomplete, errors occurred!
See also "$(HOME)/build/CMakeFiles/CMakeOutput.log".
See also "$(HOME)/build/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
```
I can only work around this by commenting out the four lines starting at
line 1443 of Tests/CMakeLists.txt.
I do have GTK2 (2.12.12) but I was on an old system (FC9), and your
FindGTK2 expects too much and errors out, blocking the build.3.8.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/16651FindHDF5: wrong use of LANGUAGE in loop2017-05-04T16:23:48-04:00Kris ThielemansFindHDF5: wrong use of LANGUAGE in loopCommit fdfb0c064929786fa1d09670cc4569b22c7c22ca introduced a loop
> foreach(__lang IN LISTS HDF5_LANGUAGE_BINDINGS)
(currently on line 667)
but some of the lines in the loop use `${LANGUAGE}` as opposed to `${__lang}`. This must me...Commit fdfb0c064929786fa1d09670cc4569b22c7c22ca introduced a loop
> foreach(__lang IN LISTS HDF5_LANGUAGE_BINDINGS)
(currently on line 667)
but some of the lines in the loop use `${LANGUAGE}` as opposed to `${__lang}`. This must mean that the code is broken.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16648Running from a path with lowercase drive letter causes misconfigured project ...2017-05-04T16:23:48-04:00drivehappyRunning from a path with lowercase drive letter causes misconfigured project filesIt appears that when attempting to run cmake.exe from a path with a lower-case drive letter present it will fail to load settings from "shared/cmake-*/Modules". This was observed when attempting to generate the AWS C++ SDK project files ...It appears that when attempting to run cmake.exe from a path with a lower-case drive letter present it will fail to load settings from "shared/cmake-*/Modules". This was observed when attempting to generate the AWS C++ SDK project files and results in a misconfigured project file where some libraries are missing their ".lib" file extension. This then causes the MSVC linker to assume a file extension of ".obj" and fail.
Reproduce notes (Windows and VS2015):
1. Download the AWS SDK: https://github.com/aws/aws-sdk-cpp/releases
(this is a useful project, as it was observed with several additional libraries configured for linking)
2. Install CMake (versions 3.4 and later seem to have the bug)
3. Run the following within a clean build target directory (ensuring that the leading drive letter "c:" is lower-case):
> "c:\Program Files\CMake\bin\cmake.exe" -G "Visual Studio 14 Win64" -DENABLE_TESTING=OFF -DBUILD_ONLY=core C:\dev\aws-sdk-cpp-1.0.69
4. Observe that the produced "aws-cpp-sdk-core/aws-cpp-sdk-core.vcxproj" file contains invalid library names within AdditionalDependencies (there are some other misconfiguration issues as well):
> Userenv;Rpcrt4;version;Wininet;winhttp;Bcrypt
5. Expected names are:
>Userenv.lib;Rpcrt4.lib;version.lib;Wininet.lib;winhttp.lib;Bcrypt.lib
This used to work with CMake 3.3, and appears to be a regression possibly caused by http://review.source.kitware.com/#/c/19985/1/SystemTools.cxx
This fix in SystemTools.cxx seems to resolve the problem (cmSystemTools.cxx):
`cmSystemToolsCMakeRoot = GetActualCaseForPath(prefix + CMAKE_DATA_DIR);`
My workaround in the meantime is to ensure that the full path provided when running CMake has a capitalized drive letter.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16646ctest svn update no longer gathers information about changes2017-05-04T16:23:48-04:00Clinton Stimpsonctest svn update no longer gathers information about changesIn CMake 3.6, a ctest_update() would correctly gather who made changes to which files.
In CMake 3.7 and 3.8, that no longer works.
The LastUpdate_*.log file for 3.6 contains
> --- Begin Revisions ---
> "/usr/bin/svn" "log" "--xml" "-v"...In CMake 3.6, a ctest_update() would correctly gather who made changes to which files.
In CMake 3.7 and 3.8, that no longer works.
The LastUpdate_*.log file for 3.6 contains
> --- Begin Revisions ---
> "/usr/bin/svn" "log" "--xml" "-v" "-r406900:407003" "" "--non-interactive"
> log-out> <?xml version="1.0" encoding="UTF-8"?>
> ...
For CMake 3.7 and 3.8, the LastUpdate_*.log file contains
> --- Begin Revisions ---
> "/usr/bin/svn" "log" "--xml" "-v" "-r:407003" "" "--non-interactive"
> log-err> svn: E205000: Syntax error in revision argument ':407003'3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16624BLA_VENDOR documentation not rendered correctly in FindBLAS/FindLAPACK docume...2017-05-04T16:23:49-04:00Silvio TraversaroBLA_VENDOR documentation not rendered correctly in FindBLAS/FindLAPACK documentationThe documentation on the possible values of the `BLA_VENDOR` variable supported in `FindBLAS` and `FindLAPACK` is not rendered correctly (or a least, it is not rendered *nicely*):
* https://cmake.org/cmake/help/v3.7/module/FindBLAS.html
...The documentation on the possible values of the `BLA_VENDOR` variable supported in `FindBLAS` and `FindLAPACK` is not rendered correctly (or a least, it is not rendered *nicely*):
* https://cmake.org/cmake/help/v3.7/module/FindBLAS.html
* https://cmake.org/cmake/help/v3.7/module/FindLAPACK.html3.8.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16620find_package(PythonInterp) + find_package(PythonLibs) problem with CMake >= 3...2017-05-04T16:23:49-04:00Cyrus Harrisonfind_package(PythonInterp) + find_package(PythonLibs) problem with CMake >= 3.4 on linuxHit this issue while evaluation moving from CMake 3.3 to CMake 3.7.
We want to seed which python libs we want to look for by calling find_package(PythonInterp), which sets the PYTHON_LIBRARY path, before calling find_package(PythonLib...Hit this issue while evaluation moving from CMake 3.3 to CMake 3.7.
We want to seed which python libs we want to look for by calling find_package(PythonInterp), which sets the PYTHON_LIBRARY path, before calling find_package(PythonLibs)
This is consistent with the docs here:
https://cmake.org/cmake/help/v3.7/module/FindPythonLibs.html
Starting with CMake 3.4, this started failing for us on a few linux platforms.
Here is the problem:
get_filename_component inside of FindPythonLibs.cmake fails b/c PYTHON_LIBRARY contains two entires:
The python lib (libpython2.7.so) and a symlink to it (libpython2.7.so.1.0)
get_filename_component expects a single entry. This error propagates and halts the configure.
Things works for us with CMake 3.3.
Below is a patch that avoids the issue, but not sure if it’s the ideal solution.
If PYTHON_LIBRARY is really supposed to be a single path, there could be other CMake logic undermined by the fact PythonInterp produces a list in some cases.
```patch
diff -c cmake-3.7.2/Modules/FindPythonLibs.cmake cmake-3.7.2-patch/Modules/FindPythonLibs.cmake
*** cmake-3.7.2/Modules/FindPythonLibs.cmake 2017-01-13 06:05:41.000000000 -0800
--- cmake-3.7.2-patch/Modules/FindPythonLibs.cmake 2017-01-31 14:28:21.000000000 -0800
***************
*** 168,174 ****
# Use the library's install prefix as a hint
set(_Python_INCLUDE_PATH_HINT)
! get_filename_component(_Python_PREFIX ${PYTHON_LIBRARY} PATH)
get_filename_component(_Python_PREFIX ${_Python_PREFIX} PATH)
if(_Python_PREFIX)
set(_Python_INCLUDE_PATH_HINT ${_Python_PREFIX}/include)
--- 168,181 ----
# Use the library's install prefix as a hint
set(_Python_INCLUDE_PATH_HINT)
! # get_filename_component(_Python_PREFIX ${PYTHON_LIBRARY} PATH)
! # the above fails when find_package(PythonInterp) returns a list with
! # both the python lib and a symlink to it.
! #
! # prevent this case by only using the first item in ${PYTHON_LIBRARY}
! # as input to get_filename_component
! list(GET ${PYTHON_LIBRARY} 0 FIRST_FOUND_PYTHON_LIBRARY)
! get_filename_component(_Python_PREFIX ${FIRST_FOUND_PYTHON_LIBRARY} PATH)
get_filename_component(_Python_PREFIX ${_Python_PREFIX} PATH)
if(_Python_PREFIX)
set(_Python_INCLUDE_PATH_HINT ${_Python_PREFIX}/include)
```
(Note: I posted this to the cmake list as well -- but here are some more links that show exactly how we are using this logic:)
https://github.com/LLNL/conduit/blob/master/src/CMake/thirdparty/SetupPython.cmake
And though its a bit verbose, you should be able to see an example of the error here:
https://circleci.com/gh/cyrush/staged-recipes/7
-Cyrus3.8.0https://gitlab.kitware.com/cmake/cmake/-/issues/16616package components and NOTFOUND_MESSAGE vs NOT_FOUND_MESSAGE2017-09-01T17:24:49-04:00chuck cranorpackage components and NOTFOUND_MESSAGE vs NOT_FOUND_MESSAGEThere is a mismatch between the cmake documentation on package components and the package code in cmFindPackageCommand.cxx. The documentation uses "NOTFOUND_MESSAGE" but the source code uses "NOT_FOUND_MESSAGE".
Details:
The document...There is a mismatch between the cmake documentation on package components and the package code in cmFindPackageCommand.cxx. The documentation uses "NOTFOUND_MESSAGE" but the source code uses "NOT_FOUND_MESSAGE".
Details:
The documentation says:
https://cmake.org/cmake/help/v3.7/manual/cmake-packages.7.html
"Here, the ClimbingStats_NOTFOUND_MESSAGE is set to a diagnosis that the package could not be found because an invalid component was specified. This message variable can be set for any case where the _FOUND variable is set to False, and will be displayed to the user."
But the current code in cmake git for Source/cmFindPackageCommand.cxx uses "NOT_FOUND" (note underline) instead of NOTFOUND:
```
bool cmFindPackageCommand::HandlePackageMode()
...
std::string foundVar = this->Name;
foundVar += "_FOUND";
std::string notFoundMessageVar = this->Name;
notFoundMessageVar += "_NOT_FOUND_MESSAGE";
std::string notFoundMessage;
...
if (configFileSetFOUNDFalse) {
/* clang-format off */
e << "Found package configuration file:\n"
" " << this->FileFound << "\n"
"but it set " << foundVar << " to FALSE so package \"" <<
this->Name << "\" is considered to be NOT FOUND.";
/* clang-format on */
if (!notFoundMessage.empty()) {
e << " Reason given by package: \n" << notFoundMessage << "\n";
}
}
```
I verified this by putting the following in a config file:
```
foreach (comp ${pdlfs-common_FIND_COMPONENTS})
if (NOT ";${PDLFS_ALL_COMPONENTS};" MATCHES ";${comp};")
set(pdlfs-common_FOUND False)
set(pdlfs-common_NOT_FOUND_MESSAGE
"[NOT_FOUND] Specified unsupported component: ${comp}")
set(pdlfs-common_NOTFOUND_MESSAGE
"[NOTFOUND] Specified unsupported component: ${comp}")
endif()
endforeach()
```
and then ran cmake with a missing component "test":
```
% grep find_pack ../CMakeLists.txt
find_package(pdlfs-common REQUIRED COMPONENTS test CONFIG)
% cmake ..
CMake Error at CMakeLists.txt:3 (find_package):
Found package configuration file:
/tmp/xccc/share/cmake/pdlfs-common/pdlfs-common-config.cmake
but it set pdlfs-common_FOUND to FALSE so package "pdlfs-common" is
considered to be NOT FOUND. Reason given by package:
[NOT_FOUND] Specified unsupported component: test
-- Configuring incomplete, errors occurred!
See also "/tmp/try3/b/CMakeFiles/CMakeOutput.log".
%
```
Which form is the correct one? "NOTFOUND" or "NOT_FOUND"?3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16568CMake ExternalProject_Add URL_HASH should not be case sensitive2017-05-04T16:23:51-04:00Joe ThompsonCMake ExternalProject_Add URL_HASH should not be case sensitiveI upgraded from CMake 3.5.2 to CMake 3.7.1
In my ExternalProject_Add commands, my URL_HASH arguments are in upper case.
With 3.7.1, this causes the following error(s):
``
does not match expected value
expected: '240FD398DA741...I upgraded from CMake 3.5.2 to CMake 3.7.1
In my ExternalProject_Add commands, my URL_HASH arguments are in upper case.
With 3.7.1, this causes the following error(s):
``
does not match expected value
expected: '240FD398DA741669BF3C90366F58452EA59041CACC741A489B99F2F6A0BAD052'
actual: '240fd398da741669bf3c90366f58452ea59041cacc741a489b99f2f6a0bad052'
``
As the alpha characters represent hex digits, I can see no advantage to making this test case sensitive.
(and possibly breaking existing CMake scripts)
You should either revert the test to be case insensitive or document that the argument must be lower case.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16566FindHDF5: does not find zlib and libdl with HDF5_ROOT since rework in 3.62019-02-04T06:13:10-05:00ThomasFindHDF5: does not find zlib and libdl with HDF5_ROOT since rework in 3.6I don't know whether this was intended, but since the rework of the FindHDF5 with 3.6 external libraries like the zlib or libdl are not found or included anymore. The variables HDF5_z_LIBRARY_(RELEASE/DEBUG) and HDF5_dl_LIBRARY_(RELEASE/...I don't know whether this was intended, but since the rework of the FindHDF5 with 3.6 external libraries like the zlib or libdl are not found or included anymore. The variables HDF5_z_LIBRARY_(RELEASE/DEBUG) and HDF5_dl_LIBRARY_(RELEASE/DEBUG) are no longer set. Depending on the HDF5 compile options other libraries may be affected as well.
The only libs that are found are the hdf5 and hdf5_{__lang} libs, as FindHDF5 only searches for these.
Tested on Ubuntu 16.04 with self-compiled HDF5 1.10-patch1 using the automake configure script and HDF5_ROOT set to correct folder.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16565Segfault in file(GLOB_RECURSE) when expression is empty2017-05-04T16:23:51-04:00Daniel LevinSegfault in file(GLOB_RECURSE) when expression is emptyCMake 3.7.1, Linux 64-bit
Trivial CMakeLists.txt:
`file(GLOB_RECURSE hello LIST_DIRECTORIES false)`
```
$ cmake .
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working C com...CMake 3.7.1, Linux 64-bit
Trivial CMakeLists.txt:
`file(GLOB_RECURSE hello LIST_DIRECTORIES false)`
```
$ cmake .
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- 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
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Segmentation fault
```3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16549Can't find Windows Store SDK with Visual Studio 2017 RC2017-05-04T16:23:51-04:00Minmin GongCan't find Windows Store SDK with Visual Studio 2017 RCTrying to create VS2017 project from CMake, with -DCMAKE_SYSTEM_VERSION=10.0 and -DCMAKE_SYSTEM_NAME=WindowsStore but fails. The error is,
> A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windo...Trying to create VS2017 project from CMake, with -DCMAKE_SYSTEM_VERSION=10.0 and -DCMAKE_SYSTEM_NAME=WindowsStore but fails. The error is,
> A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windows Store '10.0' SDK. Please make sure that you have both installed.
I do have both SDKs installed, version 10.0.10493.0. And same parameters work on VS2015.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16537Ninja generator adds "/DEF" linker flag for static libraries2017-05-04T16:23:51-04:00John SmithNinja generator adds "/DEF" linker flag for static librariesSome of my Windows code statically links against [FreeRDP](https://github.com/FreeRDP/FreeRDP). Previously I was using the "NMake Makefiles JOM" generator with [jom](https://wiki.qt.io/Jom) to build my code. The code built fine. In th...Some of my Windows code statically links against [FreeRDP](https://github.com/FreeRDP/FreeRDP). Previously I was using the "NMake Makefiles JOM" generator with [jom](https://wiki.qt.io/Jom) to build my code. The code built fine. In the past, I also used regular nmake without problems.
Recently I switched to using the "Ninja" generator with [ninja](https://ninja-build.org/). The code still compiled fine, but I ran into problems running my executable. Every time I ran the executable, Windows would complain that "freerdp-client.dll" was missing. That was odd because I explicitly told FreeRDP to be built as a static library by putting this in my CMakeLists.txt:
```
set(BUILD_SHARED_LIBS OFF)
```
I eventually tracked the problem down to this code from [client/common/CMakeLists.txt around line 42](https://github.com/FreeRDP/FreeRDP/blob/6fa36081112c46951096cddfacc0f760e4728b25/client/common/CMakeLists.txt#L42):
```
if(MSVC)
set(${MODULE_PREFIX}_SRCS ${${MODULE_PREFIX}_SRCS} module.def)
endif()
```
That line of code was causing the Ninja generator to add this linker flag to `LINK_FLAGS`:
```
/DEF:C:\path\to\FreeRDP\client\common\module.def
```
I think the `/DEF` linker flag was causing the linker to link freerdp-client.lib dynamically instead of statically to my code. The NMake and JOM generators did not add `/DEF`to `LINK_FLAGS` even though I was using the same `CMakeLists.txt`. This difference in behavior was introduced recently in 43ce4414c479af6b04e93decaf7f69938c92a323, which added this code to `cmNinjaNormalTargetGenerator::WriteDeviceLinkStatement` around line [660](https://gitlab.kitware.com/robertmaynard/cmake/commit/43ce4414c479af6b04e93decaf7f69938c92a323#e41573099084ba2bf39bf06a506af881f053382c_421_660):
```
this->AddModuleDefinitionFlag(linkLineComputer.get(), vars["LINK_FLAGS"]);
```
Inside `AddModuleDefinitionFlag`, the `/DEF` linker flag is added if a module definition file is in the list of sources. I don't see the Nmake or JOM generators calling `AddModuleDefinitionFlag` at all. Given that my code compiles and links correctly with JOM and NMake, I suspect this is a bug in the Ninja generator but I am not sure.
I confirmed that removing `module.def` from the list of sources removes `/DEF` from `LINK_FLAGS` when using the Ninja generator and that my executable now runs correctly without looking for `freerdp-client.dll`.
Coincidentally, the FreeRDP project recently modified their CMakeLists.txt files in [PR 3168](https://github.com/FreeRDP/FreeRDP/pull/3168) to [completely remove module.def from the list of sources](https://github.com/FreeRDP/FreeRDP/pull/3168/commits/c182be093dd909da953e87b3cdeb188e71e7bb73). Thus, this problem should fix itself when I eventually upgrade to the latest version of FreeRDP but it still doesn't explain the difference between the Nmake/JOM and Ninja generators.3.8.0Brad KingBrad King