CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-03-24T11:58:31-04:00https://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.https://gitlab.kitware.com/cmake/cmake/-/issues/16951CMake: Enable parallel builds by default when using `--build` command line op...2020-02-03T04:42:09-05:00Florian MaushartCMake: Enable parallel builds by default when using `--build` command line optionI want to pick up the discussion from https://blog.kitware.com/cmake-building-with-all-your-cores/ where @bill-hoffman commented:
> The only part of CMake that could learn these flags would be the `--build` part of CMake. CMake is a m...I want to pick up the discussion from https://blog.kitware.com/cmake-building-with-all-your-cores/ where @bill-hoffman commented:
> The only part of CMake that could learn these flags would be the `--build` part of CMake. CMake is a meta build tool, and at the end of the day it creates some build files, and then you don’t run CMake again. So, there really would not be a way to force parallelism from CMake other than in the `--build` option.
I think it would be a nice touch for CMake users if we take the good hints from the blog post's discussion and make it the default. And I would restrict this defaulting to *"Target Level Parallelism"*.
For me CMake is an great abstraction layer for the build environment and users may not want to learn the `make` flag details. So more advanced users could still overwrite the defaults with their own flags if they want to (or already have).
I'm willing to do the necessary CMake code changes, but I wanted to discuss possible concerns first.
My summary of what could be a starting point (with N being the number of cores determined by CMake):
- GNU Make: -j -l N
- MSBuild: /m
- JOM / Ninja: already the default
And some reference:
- https://cmake.org/pipermail/cmake/2011-November/047783.html
- https://stackoverflow.com/questions/10688549/how-to-configure-portable-parallel-builds-in-cmake
- https://stackoverflow.com/questions/36633074/how-to-setup-the-number-of-threads-in-cmake-build-from-the-command-line
- https://stackoverflow.com/questions/44433285/parallel-commands-in-cmakehttps://gitlab.kitware.com/cmake/cmake/-/issues/16949CTest launchers match "Warning" in source file names emitted by MSVC2017-06-08T08:21:45-04:00Brad KingCTest launchers match "Warning" in source file names emitted by MSVCThe default regex that matches "Warning" in compiler output triggers on source files whose names start in "Warning" because MSVC emits the source file name while compiling.The default regex that matches "Warning" in compiler output triggers on source files whose names start in "Warning" because MSVC emits the source file name while compiling.https://gitlab.kitware.com/cmake/cmake/-/issues/16943libelf RPATH parsing / install time substitution on Windows2017-07-07T10:33:11-04:00Nils Gladitzlibelf RPATH parsing / install time substitution on WindowsAssuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a ...Assuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a cross-compile setup targeting Linux.https://gitlab.kitware.com/cmake/cmake/-/issues/16937Windows MSI installer flashes briefly and exits2017-07-07T10:33:29-04:00Dan WolfWindows MSI installer flashes briefly and exitsAfter downloading the Windows MSI for 3.8.2, I ran it, but after a flash of a dialog (not even sure it has words populate), it exits. There are no error messages. I'm using Windows 10 with the latest Creator's Update.After downloading the Windows MSI for 3.8.2, I ran it, but after a flash of a dialog (not even sure it has words populate), it exits. There are no error messages. I'm using Windows 10 with the latest Creator's Update.https://gitlab.kitware.com/cmake/cmake/-/issues/16936CPack Uploads Generated ZIP ?2017-06-04T06:26:06-04:00Bo ZhouCPack Uploads Generated ZIP ?Hi
Is there anyway to upload the generated .zip file though the CPack ? Seems that file(UPLOAD) requires the target name but how should I do ? Thanks very much.Hi
Is there anyway to upload the generated .zip file though the CPack ? Seems that file(UPLOAD) requires the target name but how should I do ? Thanks very much.https://gitlab.kitware.com/cmake/cmake/-/issues/16935Add TARGET_COMPILE_PDB_NAME generator expression2021-04-22T10:32:35-04:00Walter GrayAdd TARGET_COMPILE_PDB_NAME generator expressionI'd like to be able to query the PDB name of a target so that I can add it to the install package, however there does not appear to be any way for me to query the default PDB name for a given .libI'd like to be able to query the PDB name of a target so that I can add it to the install package, however there does not appear to be any way for me to query the default PDB name for a given .libhttps://gitlab.kitware.com/cmake/cmake/-/issues/16929target_sources(interface_lib INTERFACE $<TARGET_OBJECTS:obj_lib>) does not work2017-07-07T10:36:21-04:00Changsheng Jiangtarget_sources(interface_lib INTERFACE $<TARGET_OBJECTS:obj_lib>) does not workAs the title, cmake will blame about could not find the source OBJECT_FILE_NAME with tried extensions .h, .c, ...
If it's supported, object library will be more useful.As the title, cmake will blame about could not find the source OBJECT_FILE_NAME with tried extensions .h, .c, ...
If it's supported, object library will be more useful.https://gitlab.kitware.com/cmake/cmake/-/issues/16928Add support for making fixup_bundle warnings fatal2017-06-05T09:41:21-04:00Elvis StansvikAdd support for making fixup_bundle warnings fatalIf I get warnings like e.g.
"warning: target '@rpath/QtSvg.framework/Versions/5/QtSvg' is not absolute..."
they're often indicative of a serious problem (in this case, my macOS DMG is broken because of this).
It would be nice if t...If I get warnings like e.g.
"warning: target '@rpath/QtSvg.framework/Versions/5/QtSvg' is not absolute..."
they're often indicative of a serious problem (in this case, my macOS DMG is broken because of this).
It would be nice if there was say a `FATAL_WARNINGS` parameter to `fixup_bundle`, so that my CI can catch things like this without having to parse build output, which is fragile.https://gitlab.kitware.com/cmake/cmake/-/issues/16922Impossible to build single cpp file using mingw32-make when the header file n...2017-05-25T10:31:02-04:00Marek BělImpossible to build single cpp file using mingw32-make when the header file needed is generated from subfolderIn my project, lot of c++ source files includes generated header. It is possible to successfully build whole project but it is not possible to compile single cxx file. Minimal example project attached.
command:
`mingw32-make tutorial...In my project, lot of c++ source files includes generated header. It is possible to successfully build whole project but it is not possible to compile single cxx file. Minimal example project attached.
command:
`mingw32-make tutorial.obj`
output:
```
Building CXX object CMakeFiles/Tutorial.dir/tutorial.cxx.obj
D:\Workset\cmake_example\tutorial.cxx:5:19: fatal error: Table.h: No such file or directory
```
looks like CMake doesn't add dependency between Table.h and tutorial.cxx. So let's add it by hand:
If `#SET_SOURCE_FILES_PROPERTIES(tutorial.cxx PROPERTIES OBJECT_DEPENDS ${PROJECT_BINARY_DIR}/Table.h)` is uncommented:
command:
`mingw32-make tutorial.obj`
output:
```
mingw32-make[1]: *** No rule to make target 'Table.h', needed by 'CMakeFiles/Tutorial.dir/tutorial.cxx.obj'. Stop.
Makefile:157: recipe for target 'tutorial.cxx.obj' failed
mingw32-make: *** [tutorial.cxx.obj] Error 2
```
CMake still doesn't know, how to produce file Table.h, so lets put custom target building this file instead of filename to tutorial.cxx dependencies.
Replace `#SET_SOURCE_FILES_PROPERTIES(tutorial.cxx PROPERTIES OBJECT_DEPENDS ${PROJECT_BINARY_DIR}/Table.h)` by `SET_SOURCE_FILES_PROPERTIES(tutorial.cxx PROPERTIES OBJECT_DEPENDS generate_res)`:
command:
`mingw32-make tutorial.obj`
output:
```
mingw32-make[1]: *** No rule to make target 'generate_res', needed by 'CMakeFiles/Tutorial.dir/tutorial.cxx.obj'. Stop.
```
[cmake_example_compile_single_file.zip](/uploads/8fe795ecb5f4487247d4e092f6763e70/cmake_example_compile_single_file.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/16921Cannot set debian package dependency after include(CPack)2017-05-25T17:54:29-04:00Peter-Frank SpierenburgCannot set debian package dependency after include(CPack)I am using Ubuntu 16.04 and CMake 3.5
My goal is to produce two debian packages, a -lib package that contains a shared library, and a -dev package that contains the headers and depends on the -lib.
I originally tried to use the `cp...I am using Ubuntu 16.04 and CMake 3.5
My goal is to produce two debian packages, a -lib package that contains a shared library, and a -dev package that contains the headers and depends on the -lib.
I originally tried to use the `cpack_add_component` defined by CPack, but couldn't make it work. I've posted about that on StackOverflow: https://stackoverflow.com/questions/44166400/cmake-cpack-doesnt-recognize-inter-component-dependencies
As an alternative I decided instead to try using `CPACK_DEBIAN_<component>_PACKAGE_DEPENDS`. Here is my `CMakeLists.txt` file:
```cmake
cmake_minimum_required(VERSION 3.5)
project(libmy)
include_directories(include)
add_library(my SHARED src/main/my.c)
install(TARGETS my
DESTINATION /usr/local/lib/
COMPONENT lib)
install(FILES include/my.h
DESTINATION /usr/local/include
COMPONENT dev)
set(CPACK_GENERATOR "DEB")
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me")
include(CPack)
set(CPACK_DEBIAN_DEV_PACKAGE_DEPENDS "${CPACK_PACKAGE_NAME}-lib (=${CPACK_PACKAGE_VERSION})")
```
This seems to fall down on the order of the `include(CPack)` and the `set(CPACK_DEBIAN_DEV_PACKAGE_DEPENDS "${CPACK_PACKAGE_NAME}-lib (=${CPACK_PACKAGE_VERSION})")`
In the order listed above, CPack ignores the `CPACK_DEBIAN_DEV_PACKAGE_DEPENDS` directive entirely, not adding an appropriate entry to the control file.
However, if I switch the order, I get an entry that has no `${CPACK_PACKAGE_NAME}` or `${CPACK_PACKAGE_VERSION}`.https://gitlab.kitware.com/cmake/cmake/-/issues/16919Do not emit -isystem for INSTALL_INCLUDE_PATH2018-08-30T11:11:54-04:00Demi Marie ObenourDo not emit -isystem for INSTALL_INCLUDE_PATHWhen running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilat...When running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilation to fail with:
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ext/string_conversions.h:41:0,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/basic_string.h:6157,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/string:52,
from /usr/x86_64-w64-mingw32/sys-oot/mingw/include/boost/test/utils/basic_cstring/bcs_char_traits.hpp:25,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/utils/basic_cstring/basic_cstring.hpp:21,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/detail/global_typedef.hpp:15,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tree/observer.hpp:17,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test_log.hpp:18,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tools/old/impl.hpp:19,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/test_tools.hpp:46,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test.hpp:18,
from /home/dobenour/repos/SlipRock/src/test.cpp:16:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
The culprit is that CMake generates `-isystem` flags pointing to `INCLUDE_INSTALL_DIR`, when it should use plain `-I`.
Tested with version 3.8.1 from Fedora. There was a [GCC bug] about this behavior on GCC’s part, which was closed as WONTFIX.
[GCC bug]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129https://gitlab.kitware.com/cmake/cmake/-/issues/16914Add support for CPACK_RPM_<COMPONENT>_VERSION2017-10-08T22:47:01-04:00Bram VeldhoenAdd support for CPACK_RPM_<COMPONENT>_VERSIONIt would be helpful to be able to specify the variable `CPACK_RPM_<COMPONENT>_VERSION` (and most likely the `CPACK_RPM_<COMPONENT>_VERSION_MAJOR`, `CPACK_RPM_<COMPONENT>_VERSION_MINOR`, `CPACK_RPM_<COMPONENT>_VERSION_PATCH` variables) in...It would be helpful to be able to specify the variable `CPACK_RPM_<COMPONENT>_VERSION` (and most likely the `CPACK_RPM_<COMPONENT>_VERSION_MAJOR`, `CPACK_RPM_<COMPONENT>_VERSION_MINOR`, `CPACK_RPM_<COMPONENT>_VERSION_PATCH` variables) in order to be able to generate components for which the versions are different.Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16911GHS - Multi7 and Integrity IOT compatability2024-02-01T09:21:08-05:00Fred BaksikGHS - Multi7 and Integrity IOT compatabilityOne of the features of Multi7 and GHS compilers 2015.1 and newer is that it allows for multiple configurations to be chosen to be built. For the BSP that I am using the choices are Debug / Checked / Release. This in turn picks which opt...One of the features of Multi7 and GHS compilers 2015.1 and newer is that it allows for multiple configurations to be chosen to be built. For the BSP that I am using the choices are Debug / Checked / Release. This in turn picks which option files to use and include in the top-level project. One of the items that is set is the build directory location and where object files are stored after generation. This conflicts with the current ``Green Hills MULTI`` generator that hard codes the object file output in the sub-projects.https://gitlab.kitware.com/cmake/cmake/-/issues/16910QT5_ADD_RESOURCES with generated .qrc triggers "ninja: warning: multiple rule...2018-02-15T10:19:31-05:00MrHackyQT5_ADD_RESOURCES with generated .qrc triggers "ninja: warning: multiple rules generate..."When passing a .qrc file to QT5_ADD_RESOURCES which is generated using add_custom_command, ninja will complain about there being multiple rules to generate the .qrc file.
To reproduce: (from directory containing files: [CMakeLists.txt](...When passing a .qrc file to QT5_ADD_RESOURCES which is generated using add_custom_command, ninja will complain about there being multiple rules to generate the .qrc file.
To reproduce: (from directory containing files: [CMakeLists.txt](/uploads/04f17a45124e0a1e9ec3e3ab0e5c43e8/CMakeLists.txt) [test.qrc.in](/uploads/b6c0df2cd2a58e92f1dcb5e67ec4352e/test.qrc.in))
`mkdir build && cd build
cmake .. -G Ninja
ninja
cmake .
ninja
`
Note that only the second ninja call will generate the warning. Also in this reduced example everything still seems to work fine in spite of the warning, but in our real build system where we encountered this issue ninja would sometimes get into an infinite loop and abort the build completely.
(cmake 3.7.2, ninja 1.7.2)