CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-06-30T00:01:20-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17023setting CMAKE_RUNTIME_OUTPUT_DIRECTORY on OS X w/ the makefile generator brea...2017-06-30T00:01:20-04:00Edward Ruddsetting CMAKE_RUNTIME_OUTPUT_DIRECTORY on OS X w/ the makefile generator breaks linking binaries.I have a project ( https://github.com/HumbleNet/HumbleNet ) that when I build using the XCode generator everything works fine.. However when I use the Makefile generator it incorrectly generates the link.txt files.
This is recreatable w...I have a project ( https://github.com/HumbleNet/HumbleNet ) that when I build using the XCode generator everything works fine.. However when I use the Makefile generator it incorrectly generates the link.txt files.
This is recreatable with cmake 3.6.2, 3.7.1, and 3.8.2
This is what the apibuilder/CMakeFiles/APIBuilder.dir/link.txt is when I comment out the CMAKE_RUNTIME_OUTPUT_DIRECTORY assignment in the main CmakeListst.txt (line 16)
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fno-strict-aliasing -stdlib=libc++ -fvisibility=hidden -g -arch i386 -arch x86_64 -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ CMakeFiles/APIBuilder.dir/build_csharp.cpp.o CMakeFiles/APIBuilder.dir/build_export.cpp.o CMakeFiles/APIBuilder.dir/build_include.cpp.o CMakeFiles/APIBuilder.dir/build_loader.cpp.o CMakeFiles/APIBuilder.dir/builder.cpp.o CMakeFiles/APIBuilder.dir/utilities.cpp.o -o APIBuilder -Wl,-rpath,@executable_path/../Frameworks ../libjsonparser.a
However when I add that back in the "-o" ends up being ".".
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fno-strict-aliasing -stdlib=libc++ -fvisibility=hidden -g -arch i386 -arch x86_64 -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ CMakeFiles/APIBuilder.dir/build_csharp.cpp.o CMakeFiles/APIBuilder.dir/build_export.cpp.o CMakeFiles/APIBuilder.dir/build_include.cpp.o CMakeFiles/APIBuilder.dir/build_loader.cpp.o CMakeFiles/APIBuilder.dir/builder.cpp.o CMakeFiles/APIBuilder.dir/utilities.cpp.o -o . -Wl,-rpath,@executable_path/../Frameworks ../libjsonparser.a
This cmake works fine on linux using the Makefile generator.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/17013CUDA_TOOLKIT_TARGET_DIR not cached2017-06-26T10:02:52-04:00Philippe CanalCUDA_TOOLKIT_TARGET_DIR not cachedHi,
In commit 7229ae728fa703390b70a9ded5606b01214c14de the set of CUDA_TOOLKIT_TARGET_DIR in FindCUDA.cmake was re-organized and in one place it is not cached:
```
$ git grep 'set(CUDA_TOOLKIT_TARGET_DIR'
Modules/FindCUDA.cmake: unset...Hi,
In commit 7229ae728fa703390b70a9ded5606b01214c14de the set of CUDA_TOOLKIT_TARGET_DIR in FindCUDA.cmake was re-organized and in one place it is not cached:
```
$ git grep 'set(CUDA_TOOLKIT_TARGET_DIR'
Modules/FindCUDA.cmake: unset(CUDA_TOOLKIT_TARGET_DIR CACHE)
Modules/FindCUDA.cmake: set(CUDA_TOOLKIT_TARGET_DIR ${CUDA_TOOLKIT_ROOT_DIR})
Modules/FindCUDA.cmake: set(CUDA_TOOLKIT_TARGET_DIR "${CUDA_TOOLKIT_ROOT}/targets/${CUDA_TOOLKIT_TARGET_NAME}" CACHE PATH "CUDA Toolkit target location.")
Modules/FindCUDA.cmake:set(CUDA_TOOLKIT_TARGET_DIR_INTERNAL "${CUDA_TOOLKIT_TARGET_DIR}" CACHE INTERNAL
```
As result upon reconfiguring a project from which CUDA_TOOLKIT_TARGET_DIR was set by the non-cached set, the lines:
```
if(NOT "${CUDA_TOOLKIT_TARGET_DIR}" STREQUAL "${CUDA_TOOLKIT_TARGET_DIR_INTERNAL}")
cuda_unset_include_and_libraries()
endif()
```
are always triggered.
In our particular case, this means that the customization of CUDA_USE_STATIC_CUDA_RUNTIME is forgotten.
So I propose the patch:
```
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index a4dca54..c894c84 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -641,7 +641,7 @@ if(NOT CUDA_TOOLKIT_ROOT_DIR AND NOT CMAKE_CROSSCOMPILING)
string(REGEX REPLACE "[/\\\\]?bin[64]*[/\\\\]?$" "" CUDA_TOOLKIT_ROOT_DIR ${CUDA_TOOLKIT_ROOT_DIR})
# We need to force this back into the cache.
set(CUDA_TOOLKIT_ROOT_DIR ${CUDA_TOOLKIT_ROOT_DIR} CACHE PATH "Toolkit location." FORCE)
- set(CUDA_TOOLKIT_TARGET_DIR ${CUDA_TOOLKIT_ROOT_DIR})
+ set(CUDA_TOOLKIT_TARGET_DIR ${CUDA_TOOLKIT_ROOT_DIR} CACHE PATH "CUDA Toolkit target location.")
endif()
if (NOT EXISTS ${CUDA_TOOLKIT_ROOT_DIR})
```
Thanks,
Philippe Canal.https://gitlab.kitware.com/cmake/cmake/-/issues/17010Wishlist: Flaky Test Tag2019-11-15T10:09:38-05:00Mmanu ChaturvediWishlist: Flaky Test TagFor tests with non-deterministic results, like when using threads, we might find the idea of tagging a test flaky useful. The TRI/MIT project Drake uses this feature with Bazel. So in Bazel the idea is the following, it runs a flaky te...For tests with non-deterministic results, like when using threads, we might find the idea of tagging a test flaky useful. The TRI/MIT project Drake uses this feature with Bazel. So in Bazel the idea is the following, it runs a flaky test at most `n` number of times and declares it a failure iff it fails all the `n` times. 3 is their default value of `n`.
To get some ballpark figures, consider a test with 60% passing rate, the probability of it failing would be 6.4% if declared flaky in default settings.
https://bazel.build/versions/master/docs/be/common-definitions.htmlhttps://gitlab.kitware.com/cmake/cmake/-/issues/17007GetPrerequisites outputs lots of warnings when used with Windows UCRT if recu...2017-06-27T16:35:57-04:00Mika FischerGetPrerequisites outputs lots of warnings when used with Windows UCRT if recursive parameter is 0Example `CMakeLists.txt`:
```cmake
cmake_minimum_required(VERSION 3.8)
project(foo)
set(CPP_FILENAME "${CMAKE_CURRENT_BINARY_DIR}/foo.cpp")
file(WRITE "${CPP_FILENAME}" "int main() {}")
add_executable(foo "${CPP_FILENAME}")
set(SCRIPT_...Example `CMakeLists.txt`:
```cmake
cmake_minimum_required(VERSION 3.8)
project(foo)
set(CPP_FILENAME "${CMAKE_CURRENT_BINARY_DIR}/foo.cpp")
file(WRITE "${CPP_FILENAME}" "int main() {}")
add_executable(foo "${CPP_FILENAME}")
set(SCRIPT_FILENAME "${CMAKE_CURRENT_BINARY_DIR}/dependencies-$<CONFIG>.cmake")
file(GENERATE OUTPUT "${SCRIPT_FILENAME}" CONTENT "
include(GetPrerequisites)
get_prerequisites(\"$<TARGET_FILE:foo>\" PREREQUISITES 1 0 \"\" \"\")
message(STATUS \"Prerequisites: \\\"\${PREREQUISITES}\\\"\")
")
add_custom_command(TARGET foo POST_BUILD COMMAND "${CMAKE_COMMAND}" -P "${SCRIPT_FILENAME}")
```
Output:
```
λ mkdir build && cd build && cmake --version && cmake .. && cmake --build . --config Release -- /v:m /nologo
cmake version 3.9.0-rc3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
-- Building for: Visual Studio 14 2015
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/mfischer/src/videmo/cmake-bug/build
Checking Build System
CMake does not need to re-run because C:/Users/mfischer/src/videmo/cmake-bug/build/CMakeFiles/generate.stamp is up-to-date.
Building Custom Rule C:/Users/mfischer/src/videmo/cmake-bug/CMakeLists.txt
CMake does not need to re-run because C:/Users/mfischer/src/videmo/cmake-bug/build/CMakeFiles/generate.stamp is up-to-date.
foo.cpp
foo.vcxproj -> C:\Users\mfischer\src\videmo\cmake-bug\build\Release\foo.exe
--
EXEC : warning : cannot resolve item 'api-ms-win-crt-runtime-l1-1-0.dll' [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
EXEC : -- warning : gp_resolved_file_type non-absolute file 'api-ms-win-crt-runtime-l1-1-0.dll' returning type 'system' -- possibly incorrect [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
--
EXEC : warning : cannot resolve item 'api-ms-win-crt-math-l1-1-0.dll' [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
EXEC : -- warning : gp_resolved_file_type non-absolute file 'api-ms-win-crt-math-l1-1-0.dll' returning type 'system' -- possibly incorrect [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
--
EXEC : warning : cannot resolve item 'api-ms-win-crt-stdio-l1-1-0.dll' [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
EXEC : -- warning : gp_resolved_file_type non-absolute file 'api-ms-win-crt-stdio-l1-1-0.dll' returning type 'system' -- possibly incorrect [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
--
EXEC : warning : cannot resolve item 'api-ms-win-crt-locale-l1-1-0.dll' [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
EXEC : -- warning : gp_resolved_file_type non-absolute file 'api-ms-win-crt-locale-l1-1-0.dll' returning type 'system' -- possibly incorrect [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
--
EXEC : warning : cannot resolve item 'api-ms-win-crt-heap-l1-1-0.dll' [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
EXEC : -- warning : gp_resolved_file_type non-absolute file 'api-ms-win-crt-heap-l1-1-0.dll' returning type 'system' -- possibly incorrect [C:\Users\mfischer\src\videmo\cmake-bug\build\foo.vcxproj]
-- Prerequisites: ""
Building Custom Rule C:/Users/mfischer/src/videmo/cmake-bug/CMakeLists.txt
CMake does not need to re-run because C:/Users/mfischer/src/videmo/cmake-bug/build/CMakeFiles/generate.stamp is up-to-date.
```https://gitlab.kitware.com/cmake/cmake/-/issues/17001Revise the list of commands that are available when building CMake itself.2017-08-04T17:30:19-04:00Daniel PfeiferRevise the list of commands that are available when building CMake itself.When bootstrapping CMake, only a subset of all CMake commands is available. This subset contains some commands which are unnecessary (eg `fltk_wrap_ui`). It further does not contain commands that we should start using once version 3.1 is...When bootstrapping CMake, only a subset of all CMake commands is available. This subset contains some commands which are unnecessary (eg `fltk_wrap_ui`). It further does not contain commands that we should start using once version 3.1 is requried (eg `target_include_directories`). The full list of commands should be revised.https://gitlab.kitware.com/cmake/cmake/-/issues/17000Deprecate and disallow `ctest_empty_binary_directory` command.2017-07-07T09:52:00-04:00Daniel PfeiferDeprecate and disallow `ctest_empty_binary_directory` command.The `ctest_empty_binary_directory` removes the content of a directory iff the directory contains a `CMakeCache.txt` file. It may be used in CTest dashboard scripts to make a clean build.
Since CTest will create the binary directory if i...The `ctest_empty_binary_directory` removes the content of a directory iff the directory contains a `CMakeCache.txt` file. It may be used in CTest dashboard scripts to make a clean build.
Since CTest will create the binary directory if it does not exist, it is possible to remove the build directory instead of clearing it.
CTest dashboard scripts can be used for non-CMake projects. Those projects do not generate a `CMakeCache.txt` in the binary directory.
It is probably better to recommend using `file(REMOVE_RECURSE)` for doing a clean build.https://gitlab.kitware.com/cmake/cmake/-/issues/16999Disallow all deprecated commands by policies.2023-11-06T09:37:16-05:00Daniel PfeiferDisallow all deprecated commands by policies.The following commands are documented as deprecated, but not disallowed by a policy:
* [ ] write_file
* [ ] subdirs
* [ ] remove
* [ ] make_directory
* [ ] install_target
* [ ] install_programs
* [ ] install_files
* [x] exec_programThe following commands are documented as deprecated, but not disallowed by a policy:
* [ ] write_file
* [ ] subdirs
* [ ] remove
* [ ] make_directory
* [ ] install_target
* [ ] install_programs
* [ ] install_files
* [x] exec_programhttps://gitlab.kitware.com/cmake/cmake/-/issues/16998Visual Studio 2017: merge Microsoft cmake-daemon branch to master2017-09-05T09:20:41-04:00Michael StürmerVisual Studio 2017: merge Microsoft cmake-daemon branch to masterEven though it is more nice to open generated Visual Studio solutions directly I like the native CMake integration of Visual Studio 2017 very much and get more and more used to it.
There is cool stuff going on and nice features are prom...Even though it is more nice to open generated Visual Studio solutions directly I like the native CMake integration of Visual Studio 2017 very much and get more and more used to it.
There is cool stuff going on and nice features are promised for the future:
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/cmake-support-in-visual-studio-the-visual-studio-2017-rc-update
https://blogs.msdn.microsoft.com/vcblog/2017/05/10/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update
Unfortunately, the bundled Version of CMake is quite outdated and new features like C# support etc. are missing. Are there any plans (from Microsoft/Kitware/...) to merge the **cmake-daemon** branch to master?
I found the Visual Studio branch here:
https://github.com/Microsoft/CMake/tree/cmake-daemon
This would be very nice, because new features could directly be used in Visual Studio without having to merge manually or wait for updates from Microsoft. Furthermore new official CMake releases could also be used by those who are not developing/compiling CMake themselves.https://gitlab.kitware.com/cmake/cmake/-/issues/16995GitLab: Number of issues broken2017-06-22T10:07:53-04:00Michael StürmerGitLab: Number of issues brokenI know it's not CMake related, but somehow it belongs here I think: since a few days/weeks the issue count in the GitLab profile seems broken. It is stuck at **7** and does not change if items are assigned to me or closed:
![image](/upl...I know it's not CMake related, but somehow it belongs here I think: since a few days/weeks the issue count in the GitLab profile seems broken. It is stuck at **7** and does not change if items are assigned to me or closed:
![image](/uploads/4425a060e483bc225d040d003d9423b4/image.jpeg)
It's not browser related. I login from various devices.https://gitlab.kitware.com/cmake/cmake/-/issues/16990Wanted: Import support for custom targets (extra bonus: also export support)2017-07-24T17:41:59-04:00FriedrichWanted: Import support for custom targets (extra bonus: also export support)If one has a non-code products in their buildsystem, thus uses `add_custom_target()`, there is no built-in support in CMake for exporting such a custom target in CMake config files, so it could be imported and used in other projects.
Whi...If one has a non-code products in their buildsystem, thus uses `add_custom_target()`, there is no built-in support in CMake for exporting such a custom target in CMake config files, so it could be imported and used in other projects.
While that would be good to have now and then. As there can be many non-code build products where CMake might be nice to use.
At least having a new option `IMPORTED` for `add_custom_target()` (like e.g. with `add_library`) would be good to have for the start, so one can generate/write custom CMake config code which then will not result in rules in the build system generated by CMake, but still can be used to provide needed properties.
Use case:
[ECMAddQch](https://api.kde.org/ecm/module/ECMAddQch.html) from KDE's Extra-CMake-Modules provides a macro to generate Qt Compressed Help (QCH) files with the docs of the public API of a library.
If the library links to other libraries and uses things from those which then show up in the public API (e.g. base classes or types), one can integrate the generated documentation with the documentation for those other libraries, if they are also available as QCH files. To do that, one needs to reference those files during the documentation generation, with a few parameters per each QCH file of the other libraries.
To avoid having to explicitly specify all these parameters any time some other QCH file should be integrated with, the idea has been to apply the same concepts as used with code libraries: having a single target per QCH file which has all the needed parameters set as properties.
So like `target_link_libraries()` just needs the target name of imported library targets and then automatically extracts and applies things like include paths, the macro `ecm_add_qch()` just needs to get passed the target names of imported QCH targets and then gets all details from the the properties of those targets:
```
ecm_add_qch(MyLib_QCH [...] LINK_QCHS HisLib_QCH HerLib_QCH)
```
The lack of support for exporting custom targets is currently worked around by another macro `ecm_install_qch_export()`, which simulates real target export to some degree by writing custom code into a file which then is to be installed and included by the CMake config files:
```
set(_content "${_content}
if (NOT TARGET ${_target})
add_custom_target(${_target})
set_target_properties(${_target} PROPERTIES
DOXYGEN_TAGFILE \"${_tagfile_installdir}/${_tagfile_name}\"
QHP_NAMESPACE \"${_namespace}\"
QHP_NAMESPACE_VERSIONED \"${_namespace_versioned}\"
QHP_VIRTUALFOLDER \"${_virtualfolder}\"
IMPORTED TRUE
)
set_property(TARGET ${_target} PROPERTY LINK_QCHS ${_linkqchs})
endif()
"
```
(see https://cgit.kde.org/extra-cmake-modules.git/tree/modules/ECMAddQch.cmake )
The property `IMPORTED TRUE` is ignored by cmake itself of course and normal build rules are generated, so the build log is a little confusing due to all the "imported" targets showing up.
BTW, these two macros have been now deployed to all of the KDE Frameworks libraries and will be released begin of July, 2017. Example usage: https://cgit.kde.org/kjobwidgets.git/commit/?id=66510d55dbe0d50ba69a3115162a55ad2a112602
So this issue will be facing a few people around the globe, hopefully some with resources to give this a proper built-in CMake solution :)https://gitlab.kitware.com/cmake/cmake/-/issues/16985Enhance install messages with an "updating" status2017-06-16T11:36:33-04:00Patrick StorzEnhance install messages with an "updating" statusDuring installation CMake will produce output including messages
```
-- Installing: file1.txt
-- Up-to-date: file2.txt
```
This does not allow to determine wether `file2.txt` was missing prior to installation or if it has been updated.
...During installation CMake will produce output including messages
```
-- Installing: file1.txt
-- Up-to-date: file2.txt
```
This does not allow to determine wether `file2.txt` was missing prior to installation or if it has been updated.
It would therefore be useful to change the message to
```
-- Updating: file1.txt
```
if the file already existed on disk and had to be updated.https://gitlab.kitware.com/cmake/cmake/-/issues/16983Prevent ccmake from retrigerring a cmake execution before build when nothing ...2018-07-13T03:20:37-04:00Mathieu Westphal (Kitware)Prevent ccmake from retrigerring a cmake execution before build when nothing has changedonce you've run ccmake, even if you do not change anything, cmake will need to reconfigure and execute.
It would be great if one could use ccmake to take a look into variables instead of openning CMakeCache.txt.
Steps to reproduce :
...once you've run ccmake, even if you do not change anything, cmake will need to reconfigure and execute.
It would be great if one could use ccmake to take a look into variables instead of openning CMakeCache.txt.
Steps to reproduce :
* configure and compile a project
* run ccmake
* q (quit)
* make
* cmake is executedhttps://gitlab.kitware.com/cmake/cmake/-/issues/16982Wishlist: automatically enable -pipe for gcc, clang2017-07-07T09:54:48-04:00nolangeWishlist: automatically enable -pipe for gcc, clangI haven't found any adverse effects to not using it,
advantages are less filesystem accesses, and no chances of leftovers if the build gets interrupted/killed.I haven't found any adverse effects to not using it,
advantages are less filesystem accesses, and no chances of leftovers if the build gets interrupted/killed.https://gitlab.kitware.com/cmake/cmake/-/issues/16981IPO: Linking with GCC and Clang would require the used arguments for compiling2017-07-07T09:56:59-04:00nolangeIPO: Linking with GCC and Clang would require the used arguments for compilingSee the section about -flto from the [GCC Optimize Options](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html).
There are heuristics that seem to kinda work on common OS's, but they do only partially work when it comes to embedde...See the section about -flto from the [GCC Optimize Options](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html).
There are heuristics that seem to kinda work on common OS's, but they do only partially work when it comes to embedded controller.
For ARM, you have several options affection binary compatibility (fpu, vector-extensions,...), not replicating them during linking will give you an error.
In a concrete projects, these C/C++ flags where atleast required for the linker: `-mcpu=cortex-m0 -mthumb -mfloat-abi=soft -fshort-enums`
Other might work or create subtle issues, quite possibly different depending on the compilers heuristics.
To make this more reliable, the `CMAKE_*_LINK_FLAGS` for GCC/Clang should have some placeholder `<*_COMPILE_ARGS>` which expands to the same arguments (flags, includes, defines) like when compiling.https://gitlab.kitware.com/cmake/cmake/-/issues/16977support creating relocatable object target in add_library2023-03-24T11:58:31-04:00WangBinsupport creating relocatable object target in add_libraryCurrently add_library only supports SHARED STATIC and OBJECT. When developing iOS programs I find relocatable object is very useful. It can solve many problems when distributing SDKs. An relocatable object is created by linker, gather ob...Currently add_library only supports SHARED STATIC and OBJECT. When developing iOS programs I find relocatable object is very useful. It can solve many problems when distributing SDKs. An relocatable object is created by linker, gather object files into 1.
There are several advantages over static libraries:
1. The linker can copy required code from static libraries into relocatable object. It's also called partial linking. If distributing a static library, you have to provide static libraries it depends on, and add linker flags of those dependencies. While distributing a relocatable object, nothing else is required.
2. Avoid symbols conflicting. A relocatable object can hide the copied symbols from static libraries by linker, just like a shared library. If a program uses 2 SDKs (static libraries) and both depend on the same static library A, but both use modified version of A, so you can not use only one of them to let both SDKs work correctly, but linker will complain duplicated symbols if link both A.
I've tried to modify cmake source code to support relocatable object target, but It's difficult for me. Currently I use a SHARED library target and change linker flags to support relocatable object, see https://github.com/wang-bin/ios.cmake/blob/master/ios.cmake#L329 or https://github.com/wang-bin/cmake-tools/blob/master/tools.cmake#L301
Not only apple's toolchain, GNU toolchain (including mingw) also supports relocatable object.https://gitlab.kitware.com/cmake/cmake/-/issues/16976Do not rerun CMake (with wrong parameters) if CMakeCache.txt was deleted sinc...2017-07-07T12:15:00-04:00Patrick StorzDo not rerun CMake (with wrong parameters) if CMakeCache.txt was deleted since the last run*(I typically use Ninja for my builds, so will assume it here, but I guess other generators might behave similarly)*
I usually run CMake like `cmake .. -G Ninja` to generate rules for Ninja (one rule being the automatic re-run of CMake ...*(I typically use Ninja for my builds, so will assume it here, but I guess other generators might behave similarly)*
I usually run CMake like `cmake .. -G Ninja` to generate rules for Ninja (one rule being the automatic re-run of CMake if a build file changes - which is convenient and works in most cases).
**Problem:** If I "accidentally" delete CMakeCache (i.e. to test some changes to the build system), and (without remembering to invoke CMake again) run ninja it will re-run CMake for me.
**Result:** Ninja re-runs CMake - but without parameters!
This will obviously result in a completely different generator being used and will likely mess up the build directory badly.
**Ideal case:** Ninja will re-run CMake with the parameters used when running CMake for the very first time.<br/>
**Not so ideal but still better case:** Don't re-run CMake if CMakeCache is missing but warn the user about the problem.https://gitlab.kitware.com/cmake/cmake/-/issues/16973COMPILER_HAS_HIDDEN*VISIBILITY checks fail in presence of unsupported -W opti...2017-06-15T14:41:26-04:00René BertinCOMPILER_HAS_HIDDEN*VISIBILITY checks fail in presence of unsupported -W option (or link-time only option)CMake tests for C++ compiler support of the hidden visibility options by invoking the compiler and checking its diagnostics messages. This would work fine and reliably if the compiler were invoked with ONLY the test option, OR if only fe...CMake tests for C++ compiler support of the hidden visibility options by invoking the compiler and checking its diagnostics messages. This would work fine and reliably if the compiler were invoked with ONLY the test option, OR if only feedback about the option being tested were taken into account. Neither is the case. As a result the test gives false negatives when the user or build system introduces compiler options that causes compiler warning(s).
I ran into this issue because KDE's ECM add -Wdate-time to the compiler arguments, but this should be an easy test example: use clang and a warning option like `-Wblabla`. The terminal output shows
```
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Failed
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Failed
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
```
and CMakeError.log has
```
Performing C++ SOURCE FILE Test COMPILER_HAS_HIDDEN_VISIBILITY failed with the following output:
Change Dir: /path/to/kf5-kdecoration/work/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_4559c/fast"
/usr/bin/make -f CMakeFiles/cmTC_4559c.dir/build.make CMakeFiles/cmTC_4559c.dir/build
make[1]: Entering directory `/path/to/kf5-kdecoration/work/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_4559c.dir/src.cxx.o
/opt/local/bin/clang++-mp-4.0 -Wblabla -flto -DNDEBUG -std=c++11 -arch x86_64 -std=c++0x -fno-operator-names -fno-exceptions -DQT_NO_EXCEPTIONS -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -pedantic -DCOMPILER_HAS_HIDDEN_VISIBILITY -fvisibility=hidden -o CMakeFiles/cmTC_4559c.dir/src.cxx.o -c /path/to/kf5-kdecoration/work/build/CMakeFiles/CMakeTmp/src.cxx
clang: warning: argument unused during compilation: '-arch x86_64' [-Wunused-command-line-argument]
warning: unknown warning option '-Wblabla' [-Wunknown-warning-option]
1 warning generated.
Linking CXX executable cmTC_4559c
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_4559c.dir/link.txt --verbose=1
/opt/local/bin/clang++-mp-4.0 -Wblabla -flto -DNDEBUG -std=c++11 -arch x86_64 -std=c++0x -fno-operator-names -fno-exceptions -DQT_NO_EXCEPTIONS -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -pedantic -DCOMPILER_HAS_HIDDEN_VISIBILITY -Wl,-R,/opt/local/lib -Wblabla -flto -arch x86_64 -rdynamic CMakeFiles/cmTC_4559c.dir/src.cxx.o -o cmTC_4559c
clang: warning: argument unused during compilation: '-arch x86_64' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-arch x86_64' [-Wunused-command-line-argument]
make[1]: Leaving directory `/path/to/kf5-kdecoration/work/build/CMakeFiles/CMakeTmp'
Source file was:
int main() { return 0; }
```
Curiously the warning about the `-arch x86_64` command doesn't seem to interfere with the test. Still, I think that there's no guarantee that compiler warnings about options that are intended for the linker will never interfere with the testing being done.
I can see how testing, say, "hidden visibility" support as a function of the other compiler options could be useful, but ultimately that's no longer a test whether the compiler supports the option per se. I think that `COMPILER_HAS_???` tests should test using only the compiler option to be tested, plus where (and only when) needed any options that are known to influence that support.https://gitlab.kitware.com/cmake/cmake/-/issues/16966Xcode generator over twice as slow as the Ninja generator when configuring llvm2022-04-04T10:09:20-04:00Vedant KumarXcode generator over twice as slow as the Ninja generator when configuring llvmSummary:
When running cmake on the same llvm source tree, with the same configuration, I've noticed that the Xcode generator takes 10 minutes to complete, while the Ninja generator only takes 4 minutes. While the Xcode generator was r...Summary:
When running cmake on the same llvm source tree, with the same configuration, I've noticed that the Xcode generator takes 10 minutes to complete, while the Ninja generator only takes 4 minutes. While the Xcode generator was running, I ran "top" and noticed that cmake spends a fair amount of time running xcodebuild, which could slow down configuration.
Steps to reproduce:
- Set up a full, 6-repo llvm checkout in ~/src/llvm.org-master-for-xcode
Instructions for doing this: http://llvm.org/docs/GettingStarted.html#git-mirror
- Configure with Ninja:
```
xcrun cmake -G Ninja \
-DLLVM_TARGETS_TO_BUILD="X86;ARM;AArch64" \
-DCMAKE_BUILD_TYPE:STRING=Debug \
-DLLVM_ENABLE_ASSERTIONS:BOOL=On \
-DBUILD_SHARED_LIBS=On \
-DLLVM_ENABLE_MODULES=On \
-DLLVM_INCLUDE_TESTS:BOOL=On \
~/src/llvm.org-master-for-xcode/llvm
```
This takes 4 minutes on my machine.
- Configure the same source tree, with the same options, for Xcode:
```
xcrun cmake -G Xcode \
-DLLVM_TARGETS_TO_BUILD="X86;ARM;AArch64" \
-DCMAKE_BUILD_TYPE:STRING=Debug \
-DLLVM_ENABLE_ASSERTIONS:BOOL=On \
-DBUILD_SHARED_LIBS=On \
-DLLVM_ENABLE_MODULES=On \
-DLLVM_INCLUDE_TESTS:BOOL=On \
~/src/llvm.org-master-for-xcode/llvm
```
This takes 10 minutes.
Configuration:
Cmake 3.7.2
Fusion Drive (200GB SSD + 1TB HDD)https://gitlab.kitware.com/cmake/cmake/-/issues/16965CMake no longer compiles on QNX 6.52017-06-16T09:04:47-04:00Jörg RiesmeierCMake no longer compiles on QNX 6.5I just tried to compile CMake 3.8.2 (and since that did not work also CMake 3.7.2) on QNX 6.5. I thought that QNX is one of the supported platforms, but I experienced various errors, e.g. somewhere in the "cmjsoncpp" code. The [build log...I just tried to compile CMake 3.8.2 (and since that did not work also CMake 3.7.2) on QNX 6.5. I thought that QNX is one of the supported platforms, but I experienced various errors, e.g. somewhere in the "cmjsoncpp" code. The [build log](/uploads/1aa748bc729710de8f409afdf3653db3/cmake-3.8.2_build.log) (output of "make -i") is attached.https://gitlab.kitware.com/cmake/cmake/-/issues/16964[security problem] ExternalProject_Add downloads files without checking the hash2021-02-19T10:25:27-05:00yurivict[security problem] ExternalProject_Add downloads files without checking the hashExternalProject_Add(URL ...) and ExternalProject_Add(GIT_REPOSITORY ...) download files without generally checking their hash to verify authenticity of the download. Such download process is prone to various MITM attacks, when the attack...ExternalProject_Add(URL ...) and ExternalProject_Add(GIT_REPOSITORY ...) download files without generally checking their hash to verify authenticity of the download. Such download process is prone to various MITM attacks, when the attacker controls the network or DNS and substitutes the file with a malicious copy.
This is fundamentally different with the situation when the user downloads the project itself since it is the user's responsibility to verify the authenticity of downloads and to check hashes of downloaded files. ExternalProject_Add downloads files in ad-hoc fashion without
Please make URL_HASH required, and work for all downloads, not just URL ones.