CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-06-08T08:21:45-04:00https://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)https://gitlab.kitware.com/cmake/cmake/-/issues/16909CMAKE_SYSTEM_PROCESSOR is overwritten2017-05-22T09:52:46-04:00DiederickCMAKE_SYSTEM_PROCESSOR is overwrittenI'm trying to use cmake with different toolchain files to compile a library on Mac OS for armv7, armv7s, i386 and x86_64. Using toolchain files works fine, except I have to link with different libraries/frameworks based on the architectu...I'm trying to use cmake with different toolchain files to compile a library on Mac OS for armv7, armv7s, i386 and x86_64. Using toolchain files works fine, except I have to link with different libraries/frameworks based on the architecture/build. I was thinking that using CMAKE_SYSTEM_PROCESSOR was the right choice but I'm not entirely sure anymore.
When I set the CMAKE_SYSTEM_PROCESSOR in my toolchain file it's always reset to `x86_64` in my CMakeLists.txt (and external projects). I've tried using CACHED and non-cached variables. I've created a repository that can be used to reproduce the issue: https://github.com/roxlu/cmake_multi_arch
But besides this issue, I'm not sure how to handle building for the iOS simulator. When building for the iOS simulator one uses x86_64 (so CMAKE_SYSTEM_PROCESSOR would be x86_64) but I would still need to link with different libraries which are only available for iOS. In this case checking for x86_64 wouldn't be enough. Are there other options?https://gitlab.kitware.com/cmake/cmake/-/issues/16905inconsistent behaviour of option variables and policy CMP00122017-05-19T10:04:23-04:00Frank Gaedeinconsistent behaviour of option variables and policy CMP0012I am using an option variable from a CMakeLists.txt in a package configuration file and its value is changed from 1 to ON by cmake, which then triggers the warning wrt. CMP0012 (and results in the wrong package configuration for dependen...I am using an option variable from a CMakeLists.txt in a package configuration file and its value is changed from 1 to ON by cmake, which then triggers the warning wrt. CMP0012 (and results in the wrong package configuration for dependent packages):
- in CMakeLists.txt
```
OPTION( MARLINTRK_USE_GEAR "Set to OFF to not provide Gear backward compatibility " 1)
```
- in packageConfig.cmake.in
```
IF( @MARLINTRK_USE_GEAR@ )
SET( MarlinTrk_DEFINITIONS "-D MARLINTRK_BACKWARD_GEAR_WRAPPERS" )
ENDIF()
```
- which is expanded in the packageConfig.cmake file as
```
IF( ON )
SET( MarlinTrk_DEFINITIONS "-D MARLINTRK_BACKWARD_GEAR_WRAPPERS" )
ENDIF()
```
- this then causes dependent packages to not have the correct DEFINITIONS for the package
- observed with cmake version 3.3.2 and 3.6.3https://gitlab.kitware.com/cmake/cmake/-/issues/16902GHS: Quoting issues when using target_compile_options() and add_custom_command()2022-07-21T18:54:36-04:00Fred BaksikGHS: Quoting issues when using target_compile_options() and add_custom_command()When using the command in the CMakeLists.txt file
> target_compile_options(my_target
BEFORE PRIVATE
:optionsFile=\${__OPTIONDEFS}/full_c_vas_program.opt
)
the generated output was
> :optionsFile=\$${__OPTIONDEFS}/full_c_vas_pro...When using the command in the CMakeLists.txt file
> target_compile_options(my_target
BEFORE PRIVATE
:optionsFile=\${__OPTIONDEFS}/full_c_vas_program.opt
)
the generated output was
> :optionsFile=\$${__OPTIONDEFS}/full_c_vas_program.opt
I was expecting it to be
>:optionsFile=${__OPTIONDEFS}/full_c_vas_program.opt
I traced to several lines of code in ``cmOutputConverter.cxx`` where it was performing ``Makefile`` quoting. I adapted the file to not perform any special quoting when using the GHS Multi generator.
#16488 Feature 4 and Feature 5 included patches for fixing `add_custom_command()`.Fred BaksikFred Baksikhttps://gitlab.kitware.com/cmake/cmake/-/issues/16899string(REGEX REPLACE) anchoring fails2023-04-26T13:18:24-04:00Alan W. Irwinstring(REGEX REPLACE) anchoring failsIf you create the following test.cmake file:
```cmake
set(test "whatever")
string(REGEX REPLACE "(^[^-])" "x" test "${test}")
message(STATUS "test = ${test}")
```
and execute it with
```
cmake -P test.cmake
```
the resu...If you create the following test.cmake file:
```cmake
set(test "whatever")
string(REGEX REPLACE "(^[^-])" "x" test "${test}")
message(STATUS "test = ${test}")
```
and execute it with
```
cmake -P test.cmake
```
the result "xxxxxxxx" is obtained rather than the expected "xhatever". In other words the result is the same as if the regular expression does not start with the anchor.
N.B. This is a long standing issue; I get the incorrect result both for CMake-3.0.2 and 3.8.1.https://gitlab.kitware.com/cmake/cmake/-/issues/16890cmake fails when bison executable path contains spaces2017-05-16T09:27:30-04:00Carl Walshcmake fails when bison executable path contains spacesWhen I run cmake on a project that uses bison and has spaces, the generations fails with the error:
CMake Error at C:/Program Files/CMake/share/cmake-3.8/Modules/FindBISON.cmake:102 (message):
Command "C:/code/Free RCT/Libraries/win...When I run cmake on a project that uses bison and has spaces, the generations fails with the error:
CMake Error at C:/Program Files/CMake/share/cmake-3.8/Modules/FindBISON.cmake:102 (message):
Command "C:/code/Free RCT/Libraries/win_bison/bison.bat --version" failed
with output:
'C:\code\Free' is not recognized as an internal or external command,
I'm building the [FreeRCT](https://github.com/FreeRCT/FreeRCT) project on Windows, using cmake version 3.8.1
Full output:
C:\code\Free RCT\FreeRCT\build>"C:\Program Files\CMake\bin\cmake.exe" -G "Visual Studio 14 2015" -DCMAKE_INSTALL_PREFIX:PATH="/Users/carlwa/Documents/CMakeInstalls" -DCMAKE_INSTALL_PREFIX="/Users/carlwa/Documents/CMakeInstalls" -DZLIB_LIBRARY="C:/code/Free RCT/FreeRCT/../Libraries/OpenTTD_essentials/win32/library/zlibstat.lib" -DZLIB_INCLUDE_DIR="C:/code/Free RCT/FreeRCT/../Libraries/OpenTTD_essentials/shared/include/" -DPNG_LIBRARY="C:/code/Free RCT/FreeRCT/../Libraries/OpenTTD_essentials/win32/library/libpng.lib" -DPNG_PNG_INCLUDE_DIR="C:/code/Free RCT/FreeRCT/../Libraries/OpenTTD_essentials/shared/include/" -DSDL2_LIBRARY="C:/code/Free RCT/FreeRCT/../libraries/SDL2/lib/x86/SDL2.lib" -DSDL2_INCLUDE_DIR="C:/code/Free RCT/FreeRCT/../libraries/SDL2/include" -DSDL2TTF_LIBRARY="C:/code/Free RCT/FreeRCT/../libraries/SDL2_ttf/lib/x86/SDL2_ttf.lib" -DSDL2TTF_INCLUDE_DIR="C:/code/Free RCT/FreeRCT/../libraries/SDL2_ttf/include" -DBISON_EXECUTABLE="C:/code/Free RCT/FreeRCT/../Libraries/win_bison/bison.bat" -DFLEX_EXECUTABLE="C:/code/Free RCT/FreeRCT/../Libraries/win_bison/flex.bat" -DCMAKE_CONFIGURATION_TYPES="Debug" "C:\code\Free RCT\FreeRCT"
-- 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
--
-- Building rcdgen
-- Found ZLIB: C:/code/Free RCT/FreeRCT/../Libraries/OpenTTD_essentials/win32/library/zlibstat.lib (found version "1.2.7")
-- Found PNG: C:/code/Free RCT/FreeRCT/../Libraries/OpenTTD_essentials/win32/library/libpng.lib (found version "1.5.14")
CMake Error at C:/Program Files/CMake/share/cmake-3.8/Modules/FindBISON.cmake:102 (message):
Command "C:/code/Free RCT/Libraries/win_bison/bison.bat --version" failed
with output:
'C:\code\Free' is not recognized as an internal or external command,
operable program or batch file.
Call Stack (most recent call first):
src/rcdgen/CMakeLists.txt:50 (find_package)
-- Found BISON: C:/code/Free RCT/Libraries/win_bison/bison.bat
-- No bison executable found, using pregenerated parser
Command "C:/code/Free RCT/Libraries/win_bison/flex.bat --version" failed with output:
'C:\code\Free' is not recognized as an internal or external command,
operable program or batch file.
FLEX_VERSION will not be available
-- Found FLEX: C:/code/Free RCT/Libraries/win_bison/flex.bat
-- Building RCD Files
-- Building FreeRCT
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Found SDL2: C:/code/Free RCT/FreeRCT/../libraries/SDL2/lib/x86/SDL2.lib
-- Found SDL2_ttf: C:/code/Free RCT/FreeRCT/../libraries/SDL2_ttf/lib/x86/SDL2_ttf.lib
-- Could NOT find Git (missing: GIT_EXECUTABLE)
CMake Error at src/CMakeLists.txt:208 (message):
No VCS checkout detected. Enable the OVERRIDE_VCS option if this is
intended. This is not recommended.
-- Configuring incomplete, errors occurred!
See also "C:/code/Free RCT/FreeRCT/build/CMakeFiles/CMakeOutput.log".
See also "C:/code/Free RCT/FreeRCT/build/CMakeFiles/CMakeError.log".https://gitlab.kitware.com/cmake/cmake/-/issues/16886property MACOSX_PACKAGE_LOCATION does not copy frameworks and resources recur...2024-01-08T15:33:16-05:00Sandy Martelproperty MACOSX_PACKAGE_LOCATION does not copy frameworks and resources recursively with some generators[test.tar.xz](/uploads/60c51a5482def2c90e6d51e6b1c5fb7b/test.tar.xz)
I have 3rd parties private frameworks and resource folders to be copied in the application bundle, I set the MACOSX_PACKAGE_LOCATION property on them:
set_source_file...[test.tar.xz](/uploads/60c51a5482def2c90e6d51e6b1c5fb7b/test.tar.xz)
I have 3rd parties private frameworks and resource folders to be copied in the application bundle, I set the MACOSX_PACKAGE_LOCATION property on them:
set_source_files_properties( private.framework PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks )
set_source_files_properties( folder PROPERTIES MACOSX_PACKAGE_LOCATION Resources )
but they are only copied correctly when using the Xcode generator, make or ninja failed to copy the whole folder.
See attached project, run ./build.sh, compare the 2 .app generated.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16884find_package(REQUIRED) won't fail if package name capitalization isn't identi...2022-04-06T14:10:22-04:00Raul Tambreraul@tambre.eefind_package(REQUIRED) won't fail if package name capitalization isn't identical to the module'sThe examples assume that either GLEW or wxWidgets aren't already installed or can't be found by CMake.
The following:
```cmake
cmake_minimum_required(VERSION 3.8.1)
find_package(glew REQUIRED)
find_package(wxwidgets REQUIRED)
```
Will ...The examples assume that either GLEW or wxWidgets aren't already installed or can't be found by CMake.
The following:
```cmake
cmake_minimum_required(VERSION 3.8.1)
find_package(glew REQUIRED)
find_package(wxwidgets REQUIRED)
```
Will fail with:
```
Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS)
Configuring done
Generating done
```
But the following:
```cmake
cmake_minimum_required(VERSION 3.8.1)
find_package(GLEW REQUIRED)
find_package(wxWidgets REQUIRED)
```
Will fail with:
```
CMake Error at C:/Program Files/CMake/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.8/Modules/FindGLEW.cmake:38 (find_package_handle_standard_args)
CMakeLists.txt:2 (find_package)
Configuring incomplete, errors occurred!
See also "[redacted]/build/CMakeFiles/CMakeOutput.log".
```
The 1st example still executed FindGLEW and FindwxWidgets, but neither fail if the libraries aren't found. The failure was the expected result due to the `REQUIRED`. If the capitalization is exactly same as the module's, as it is in the 2nd example, then it will fail as expected. It might be worth noting the extra space after the "missing: " in the 1st example.