CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-10-13T13:17:56-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16344Add detach support to execute_process()2017-10-13T13:17:56-04:00Hendrik SattlerAdd detach support to execute_process()Hi,
There is potentially cmsysProcess_SetOption(cp, cmsysProcess_Option_Detach, 1) but it is unavailable from CMake script code.
The latest changes (3.0.2 -> 3.6.2) broke a hackish use of 'cmd /C "start /B foot"' so that a cmake -P scri...Hi,
There is potentially cmsysProcess_SetOption(cp, cmsysProcess_Option_Detach, 1) but it is unavailable from CMake script code.
The latest changes (3.0.2 -> 3.6.2) broke a hackish use of 'cmd /C "start /B foot"' so that a cmake -P script doesn't exit anymore.
Regardshttps://gitlab.kitware.com/cmake/cmake/-/issues/16343Target properties for XCode documentation improvement2017-10-13T13:17:56-04:00Robert BielikTarget properties for XCode documentation improvementThe `XCODE_ATTRIBUTE_<an-attribute>` target property lacks the information on how to set them per build type. I've came across it while searching via Google:
`XCODE_ATTRIBUTE_<an-attribute>[variant=<Build Type>]`
Please update documenta...The `XCODE_ATTRIBUTE_<an-attribute>` target property lacks the information on how to set them per build type. I've came across it while searching via Google:
`XCODE_ATTRIBUTE_<an-attribute>[variant=<Build Type>]`
Please update documentation accordingly. I know there are generator expressions, haven't tried if the same can be accomplished with them.https://gitlab.kitware.com/cmake/cmake/-/issues/16342Ninja generator breaks when creating archives with GNU 'ar' in Windows2017-10-13T13:17:56-04:00Hai NguyenNinja generator breaks when creating archives with GNU 'ar' in WindowsThis is related to these issues:
https://cmake.org/Bug/view.php?id=15278
and https://cmake.org/Bug/view.php?id=15439#c38728
The variation to the above mentioned issue is the usage of Clang and GNU 'ar' instead of of GCC and GNU 'ar'...This is related to these issues:
https://cmake.org/Bug/view.php?id=15278
and https://cmake.org/Bug/view.php?id=15439#c38728
The variation to the above mentioned issue is the usage of Clang and GNU 'ar' instead of of GCC and GNU 'ar'.
Based on what I can tell from the second issue, the fix was to detect if GCC was present and a forward slash was to be used instead. If the same thing can be applied to clang, it would be useful. Or maybe instead of it being compiler dependent, it should just see if it's GNU 'ar' since that's the common denominator.
I've tested this on cmd.exe and Git for Windows bash shell.https://gitlab.kitware.com/cmake/cmake/-/issues/16341Cannot pass empty strings to add_test(), CMAKE_PARSE_ARGUMENTS() skips empty ...2017-05-04T16:24:37-04:00SeanCannot pass empty strings to add_test(), CMAKE_PARSE_ARGUMENTS() skips empty stringsI have CTest unit tests of the form:
```
add_test(NAME test_01 COMMAND test) # test null
add_test(NAME test_01 COMMAND test "" 0) # test empty
add_test(NAME test_01 COMMAND test "a" 1) # test strings
```
This works correctly wi...I have CTest unit tests of the form:
```
add_test(NAME test_01 COMMAND test) # test null
add_test(NAME test_01 COMMAND test "" 0) # test empty
add_test(NAME test_01 COMMAND test "a" 1) # test strings
```
This works correctly with the default add_test() function! It ends up invoking:
```
test
=> argc:1 with argv[0]: "test"
test "" 0
=> argc: 3 with argv[0]: "test", argv[1]: "", argv[2]: "0"
test "a" 1
=> argc: 3 with argv[0]: "test", argv[1]: "a", argv[2]: "1"
```
However, when I create a add_test() wrapper function and pass the same data to _add_test(), the _add_test() macro is ignoring the empty string/list element:
```
function(add_test NAME test_name COMMAND test_command)
# do stuff
_add_test(NAME ${test_name} COMMAND ${test_command} ${ARGN})
endfunction(add_test)
```
Other variants with different argument lists or building up a command string have the same undesirable/unintended/wrong result:
```
test
=> argc:1 with argv[0]: "test"
test "" 0
=> argc: 2 with argv[0]: "test", argv[1]: "0"
test "a" 1
=> argc: 3 with argv[0]: "test", argv[1]: "a", argv[2]: "1"
```
Even this attempt at a forced workaround fails:
```
function(add_test NAME test_name COMMAND test_command)
# do stuff
foreach (argi IN LISTS ARGN)
list(APPEND test_command ${argi})
endforeach ()
message("adding test: test_name:${test_name} test_command:${test_command}")
_add_test(NAME ${test_name} COMMAND ${test_command})
endfunction(add_test)
```
Digging deeper, I found that CMAKE_PARSE_ARGUMENTS() seems to be skipping empty elements and presumably it is being called within _add_test(). Even when not using _add_test() with argument names, however, the behavior persists:
```
function(add_test)
# do stuff
_add_test(${ARGV})
endfunction(add_test)
```https://gitlab.kitware.com/cmake/cmake/-/issues/16339Improve default generator selection and make it configurable2020-05-13T09:34:20-04:00Jason JuangImprove default generator selection and make it configurableNow whenever I build a visual studio project I have to type `cmake .. -G "Visual Studio 14 Win64"` which is kind of tedious when compare to linux a simple `cmake ..` would work. Is there any way that I can set this up in my CMakeLists so...Now whenever I build a visual studio project I have to type `cmake .. -G "Visual Studio 14 Win64"` which is kind of tedious when compare to linux a simple `cmake ..` would work. Is there any way that I can set this up in my CMakeLists so when I type `cmake ..` it will generate 64 bit build by default?
I am using the latest cmake 3.6.2.
Related but unanswered: http://stackoverflow.com/questions/6430251/what-is-the-default-generator-for-cmake-in-windows
Thanks,
Jasonhttps://gitlab.kitware.com/cmake/cmake/-/issues/16338Ability to generate absolute project paths in solution file2017-10-13T13:17:56-04:00Mikhail PilinAbility to generate absolute project paths in solution fileThe bonus is the ability to copy solution file in any other directory without changes!
Now:
```
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ALL_BUILD", "ALL_BUILD.vcxproj", "{598C2215-E014-36B5-A468-40E8263A5414}"
```
Exp...The bonus is the ability to copy solution file in any other directory without changes!
Now:
```
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ALL_BUILD", "ALL_BUILD.vcxproj", "{598C2215-E014-36B5-A468-40E8263A5414}"
```
Expected:
```
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ALL_BUILD", "<absolute path here>\ALL_BUILD.vcxproj", "{598C2215-E014-36B5-A468-40E8263A5414}"
```https://gitlab.kitware.com/cmake/cmake/-/issues/16337GetPrerequisites.cmake may not detect 'api-ms-win*' DLLs as being 'system' ones2017-07-11T05:35:18-04:00Benoit NEILGetPrerequisites.cmake may not detect 'api-ms-win*' DLLs as being 'system' onesAs of CMake 3.6.1, function `gp_resolved_file_type` in GetPrerequisites.cmake uses this regex to detect Windows' system DLLs:
> `if(lower MATCHES "^(api-ms-win-|${sysroot}/sys(tem|wow)|${windir}/sys(tem|wow)|(.*/)*msvc[^/]+dll)")`
Unfo...As of CMake 3.6.1, function `gp_resolved_file_type` in GetPrerequisites.cmake uses this regex to detect Windows' system DLLs:
> `if(lower MATCHES "^(api-ms-win-|${sysroot}/sys(tem|wow)|${windir}/sys(tem|wow)|(.*/)*msvc[^/]+dll)")`
Unfortunately, the name resolution (from `gp_resolve_item`, near the beginning of the function) may generate a full path, especially if the DLL is not found. It is the case for me with MS Visual 2015 new CRT ; I got something like `C:/Development/MyProject/api-ms-win-core-misc-l1-1-0.dll`. I thus cannot INSTALL / PACKAGE my project as it considers this DLL as being non-system and thus is not ignored by the appropriate option.
I suggest then to generalize the regex (as for the "msvc*" DLLs):
> `if(lower MATCHES "^((.*/)*api-ms-win-[^/]+dll|${sysroot}/sys(tem|wow)|${windir}/sys(tem|wow)|(.*/)*msvc[^/]+dll)")`
Here you'll find my modified [GetPrerequisites.cmake](/uploads/5925aa2be5c3ef1c33cc80b9643e47b5/GetPrerequisites.cmake) file, against CMake 3.6.1.https://gitlab.kitware.com/cmake/cmake/-/issues/16336IMPORT_PREFIX/IMPORT_SUFFIX has no effect on Windows2018-02-20T16:28:55-05:00Eduard WirchIMPORT_PREFIX/IMPORT_SUFFIX has no effect on WindowsUsing this configuration:
```
add_library(postgresql SHARED IMPORTED)
set_target_properties(postgresql PROPERTIES
IMPORT_PREFIX lib
IMPORT_SUFFIX lib
IMPORTED_IMPLIB "${PROJECT_SOURCE_DIR}/lib/postgresql/pq"
)
```
cmake will compl...Using this configuration:
```
add_library(postgresql SHARED IMPORTED)
set_target_properties(postgresql PROPERTIES
IMPORT_PREFIX lib
IMPORT_SUFFIX lib
IMPORTED_IMPLIB "${PROJECT_SOURCE_DIR}/lib/postgresql/pq"
)
```
cmake will complain that it can't find "pq.obj", while it should look for "libpq.lib"https://gitlab.kitware.com/cmake/cmake/-/issues/16335regression: warning of missing headers when using boost python-py35 component2018-03-22T08:40:48-04:00joschregression: warning of missing headers when using boost python-py35 componentI have the following in my CMakeLists.txt:
find_package(Boost COMPONENTS python-py35 REQUIRED)
This used to work fine with cmake 3.2.2-2 from Debian. I now upgraded to cmake 3.6.1-1 and when configuring the same code I get:
C...I have the following in my CMakeLists.txt:
find_package(Boost COMPONENTS python-py35 REQUIRED)
This used to work fine with cmake 3.2.2-2 from Debian. I now upgraded to cmake 3.6.1-1 and when configuring the same code I get:
CMake Warning at /usr/share/cmake-3.6/Modules/FindBoost.cmake:1475 (message):
No header defined for python-py35; skipping header check
The code seems to build and run fine despite the warning. I do not know what it means or if there is anything to do on my part.Roger LeighRoger Leighhttps://gitlab.kitware.com/cmake/cmake/-/issues/16334unexpected location for CMakeCache, CMakeFiles and build results2018-02-20T16:28:55-05:00René Bertinunexpected location for CMakeCache, CMakeFiles and build resultsI have a project with the following layout, provided a CMake file in addition to project definitions for MSVC and Xcode (each also in dedicated directories):
```
SynchroTr
|- lib1Src
|- lib2Src
|- testApp1.c
|- testApp2.cpp
|- C...I have a project with the following layout, provided a CMake file in addition to project definitions for MSVC and Xcode (each also in dedicated directories):
```
SynchroTr
|- lib1Src
|- lib2Src
|- testApp1.c
|- testApp2.cpp
|- CMake
|- CMakeLists.txt
|- build
```
The CMakeLists.txt file contains
```
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(SynchroTr)
include(FindPkgConfig)
include(CheckFunctionExists)
include(FeatureSummary)
include_directories(${CMAKE_CURRENT_LIST_DIR}/..)
link_directories(${CMAKE_CURRENT_LIST_DIR} ${CMAKE_BINARY_DIR} ${SPARSEHASH_LIBRARY_DIRS})
add_library(lib1 STATIC ${CMAKE_CURRENT_LIST_DIR}/../lib1Src/lib1.cpp)
add_library(lib2 STATIC ${CMAKE_CURRENT_LIST_DIR}/../lib2Src/lib2.cpp)
add_executable(testApp1 ${CMAKE_CURRENT_LIST_DIR}/../testApp1.c)
target_link_libraries(testApp1 lib1)
set_target_properties(testApp1 PROPERTIES LINKER_LANGUAGE CXX)
add_executable(testApp2 ${CMAKE_CURRENT_LIST_DIR}/../testApp2.cpp)
target_link_libraries(testApp2 lib1 lib2)
```
My experience with CMake is that
> (cd build ; cmake ../CMakeLists.txt)
or
> (cd build ; cmake ../source/CMakeLists.txt)
puts all stuff for building into `build` (including CMakeCache.txt). However, when from the source directory I do
> (cd CMake/build ; cmake ../CMakeLists.txt)
the directory that is set up for building is not CMake/build, but CMake itself.
I observe this with CMake 3.6.2; I am pretty sure that it used to work as expected with an earlier version.https://gitlab.kitware.com/cmake/cmake/-/issues/16333cmake-3.6.2-win64-x64.msi: HTML help missing2018-02-20T16:28:55-05:00Hendrik Sattlercmake-3.6.2-win64-x64.msi: HTML help missingIn the cmake-3.6.2-win64-x64.msi, the HTML help is missing but it is present in cmake-3.6.2-win32-x86.msiIn the cmake-3.6.2-win64-x64.msi, the HTML help is missing but it is present in cmake-3.6.2-win32-x86.msi3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16332ninja generator fortran support: original source file directory is not search...2018-02-20T16:28:55-05:00Keith Millerninja generator fortran support: original source file directory is not searched when using fortran INCLUDE statementWhen a file is INCLUDEed in fortran, the original source directory that contains the source file with the INCLUDE statement should be searched for the included file ahead of any directories that are specified with -I. It would normally ...When a file is INCLUDEed in fortran, the original source directory that contains the source file with the INCLUDE statement should be searched for the included file ahead of any directories that are specified with -I. It would normally be functionality that is implicitly provided by the compiler, but since the pre-processed file is located out-of-tree, the original source directory may need to be added to the include path?
Please find attached test case:
[ftest.tar.xz](/uploads/ef25355d9e5bc684b7d335fe27527112/ftest.tar.xz)3.7.0Nils GladitzNils Gladitzhttps://gitlab.kitware.com/cmake/cmake/-/issues/16331FindCxxTest runs incorrect python executable2018-02-20T16:28:55-05:00Orion PoplawskiFindCxxTest runs incorrect python executableOn Fedora 24+, cxxtestgen is a python3 executable with a #!/usr/bin/python3 shbang. However, FindCxxTest calls it with /usr/bin/python, which fails. See http://public.kitware.com/pipermail/cmake/2016-August/064027.html for more.
There...On Fedora 24+, cxxtestgen is a python3 executable with a #!/usr/bin/python3 shbang. However, FindCxxTest calls it with /usr/bin/python, which fails. See http://public.kitware.com/pipermail/cmake/2016-August/064027.html for more.
There is no need to call with python explicitly on Linux/Unix. Not sure what the situation on Windows is.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16330project(... LANGUAGES C CXX RC) causes "Recursive call not allowed"2018-02-01T18:14:37-05:00Kevin Puetzproject(... LANGUAGES C CXX RC) causes "Recursive call not allowed"After upgrading from CMake 3.5.2 to 3.6.2, we are now experiencing an error
```
-- The C compiler identification is MSVC 19.0.23918.0
CMake Error at cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/Platform/Windows-MSVC.cmake:326 (enab...After upgrading from CMake 3.5.2 to 3.6.2, we are now experiencing an error
```
-- The C compiler identification is MSVC 19.0.23918.0
CMake Error at cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/Platform/Windows-MSVC.cmake:326 (enable_language):
Language 'RC' is currently being enabled. Recursive call not allowed.
Call Stack (most recent call first):
cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/Platform/Windows-MSVC-C.cmake:5 (__windows_compiler_msvc)
cmake-3.6.0-rc1-win64-x64/share/cmake-3.6/Modules/CMakeCInformation.cmake:58 (include)
CMakeLists.txt:2 (project)
```
This appears even in a minimized sample project
```
project(foo LANGUAGES C CXX RC)
```
I have reproduced it as far back as 3.6.0-rc1; in 3.5.2 and earlier, our project works fine.
My guess from skimming the history is that this regression begins after #15999/72e0dc58d3caf63a57975e97ce13c5dc4b38cf9b, though I haven't recompiled CMake to prove it.
I am not using any custom toolchain; the error seems to be independent of Generator, but the exact messages above are from the default "Visual Studio 14 2015". From the backtrace, it appears the Platform/Windows-MSVC.cmake is at fault.
Our project is explicitly enabling the RC language because we are also building for with g++ and winelib. On that platform we *do* use a toolchain file, which sets up wrc as the RC_COMPILER. But it does not enable_language, we let the projects that use .rc files do it.
```
SET(CMAKE_RC_COMPILER "${WINE_WRC}")
SET(CMAKE_RC_OUTPUT_EXTENSION .res)
SET(CMAKE_RC_SOURCE_FILE_EXTENSIONS .rc)
```3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16329NDEBUG is defined for debug build with clang toolset2017-10-13T13:17:56-04:00Sven JohannsenNDEBUG is defined for debug build with clang toolsetIf I create a new Visual Studio (2015, Update3) project for the **clang toolset**:
cmake .. -G "Visual Studio 14 2015 Win64" -Tv140_clang_c2
**NDEBUG** is defined. (Inherited value, see property window)
tested with cmake 3.6.2If I create a new Visual Studio (2015, Update3) project for the **clang toolset**:
cmake .. -G "Visual Studio 14 2015 Win64" -Tv140_clang_c2
**NDEBUG** is defined. (Inherited value, see property window)
tested with cmake 3.6.2https://gitlab.kitware.com/cmake/cmake/-/issues/16328NSIS silent installs don't have a default set for uninstaller message box2018-02-20T16:28:55-05:00Craig ScottNSIS silent installs don't have a default set for uninstaller message boxIn the [`NSIS.template.in`](https://gitlab.kitware.com/cmake/cmake/blob/v3.6.2/Modules/NSIS.template.in#L907) file, the following section of code checks for an existing install and asks the user if they want to remove it before installin...In the [`NSIS.template.in`](https://gitlab.kitware.com/cmake/cmake/blob/v3.6.2/Modules/NSIS.template.in#L907) file, the following section of code checks for an existing install and asks the user if they want to remove it before installing the new version:
```
Function .onInit
StrCmp "@CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL@" "ON" 0 inst
ReadRegStr $0 HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\@CPACK_PACKAGE_INSTALL_REGISTRY_KEY@" "UninstallString"
StrCmp $0 "" inst
MessageBox MB_YESNOCANCEL|MB_ICONEXCLAMATION \
"@CPACK_NSIS_PACKAGE_NAME@ is already installed. $\n$\nDo you want to uninstall the old version before installing the new one?" \
IDYES uninst IDNO inst
Abort
```
In the above call to `MessageBox`, there is no /SD parameter to set a default to be used for silent installs. This should probably default to answering YES to allow the new install to replace the old one. Something like the following should work:
```
MessageBox MB_YESNOCANCEL|MB_ICONEXCLAMATION \
"@CPACK_NSIS_PACKAGE_NAME@ is already installed. $\n$\nDo you want to uninstall the old version before installing the new one?" \
/SD IDYES IDYES uninst IDNO inst
```
Relevant documentation can be found [here](http://nsis.sourceforge.net/Docs/Chapter4.html#silent), but a clearer explanation is in the [example that documentation links to](http://nsis.sourceforge.net/Examples/silent.nsi).https://gitlab.kitware.com/cmake/cmake/-/issues/16327CMAKE_OSX_SYSROOT is not properly stored in CMakeCache.txt2018-02-20T16:28:56-05:00Nat!CMAKE_OSX_SYSROOT is not properly stored in CMakeCache.txtHere is a shell script (you can also just copy/paste into Terminal) that shows the the problem in **cmake version 3.6.2**. CMAKE_OSX_SYSROOT is not stored in `CMakeCache.txt`which makes a subsequent run of **cmake** produce an error:
...Here is a shell script (you can also just copy/paste into Terminal) that shows the the problem in **cmake version 3.6.2**. CMAKE_OSX_SYSROOT is not stored in `CMakeCache.txt`which makes a subsequent run of **cmake** produce an error:
```
#! /bin/sh
touch foo.c
cat <<EOF > CMakeLists.txt
cmake_minimum_required (VERSION 3.0)
set( CMAKE_OSX_SYSROOT "/") # means current OS X
set( CMAKE_OSX_DEPLOYMENT_TARGET "10.6" CACHE STRING "Deployment target for OSX" FORCE)
add_library(foo STATIC
foo.c
)
EOF
mkdir build
cd build
cmake ..
ack OSX
# CMakeCache.txt
# 119://Build architectures for OSX
# 120:CMAKE_OSX_ARCHITECTURES:STRING=
# 122://Deployment target for OSX
# 123:CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.6
# 127:CMAKE_OSX_SYSROOT:STRING=
#
cmake ..
# CMake Error at /usr/local/Cellar/cmake/3.6.2/share/cmake/Modules/Platform/Darwin.cmake:76 (message):
# CMAKE_OSX_DEPLOYMENT_TARGET is '10.6' but CMAKE_OSX_SYSROOT:
```https://gitlab.kitware.com/cmake/cmake/-/issues/16326With Xcode 8 CMake cannot detect Swift compiler2017-06-27T14:59:10-04:00Gregor JasnyWith Xcode 8 CMake cannot detect Swift compilerI get the following error:
```
Compiling the Swift compiler identification source file "CompilerId/main.swift" failed.
Compiler:
Build flags:
Id flags:
The output was:
65
=== BUILD TARGET CompilerIdSwift OF PROJECT Compil...I get the following error:
```
Compiling the Swift compiler identification source file "CompilerId/main.swift" failed.
Compiler:
Build flags:
Id flags:
The output was:
65
=== BUILD TARGET CompilerIdSwift OF PROJECT CompilerIdSwift WITH THE DEFAULT CONFIGURATION (Debug) ===
Check dependencies
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.
** BUILD FAILED **
```
The trick is to specify the required Swift version in the Xcode project:
```
isa = XCBuildConfiguration;
buildSettings = {
PRODUCT_NAME = CompilerIdSwift;
+ SWIFT_VERSION = 2.3;
};
```3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16325Deriving CMAKE_OSX_SYSROOT from CMAKE_OSX_DEPLOYMENT_TARGET is not correct2018-02-20T16:28:56-05:00Nat!Deriving CMAKE_OSX_SYSROOT from CMAKE_OSX_DEPLOYMENT_TARGET is not correctThe problem is that `CMAKE_OSX_SYSROOT` says
```
If not set explicitly the value is initialized by the SDKROOT environment variable, if set, and otherwise computed based on the CMAKE_OSX_DEPLOYMENT_TARGET or the host platform.
```
...The problem is that `CMAKE_OSX_SYSROOT` says
```
If not set explicitly the value is initialized by the SDKROOT environment variable, if set, and otherwise computed based on the CMAKE_OSX_DEPLOYMENT_TARGET or the host platform.
```
The purpose of `CMAKE_OSX_DEPLOYMENT_TARGET` is to set the *minimum* OS X version on which the product should run. `CMAKE_OSX_SYSROOT` should not concern itself with `CMAKE_OSX_DEPLOYMENT_TARGET` at all.
Here is an example to illustrate:
Let's say I write a project on 10.12. I want it to stay compatible for 10.12, even if 10.13/14/15... comes out and I compile it with the newer OS X/Xcode.
I therefore set the `CMAKE_OSX_DEPLOYMENT_TARGET` to 10.12. What I do not want, is to manually set `CMAKE_OSX_SYSROOT` everytime a new OS X version comes out. It's not neccessary.
If I don't set `CMAKE_OSX_SYSROOT` manually, then in newer OS X versions the SDK might not be present for 10.12 and cmake fails! But the presence of the 10.12 SDK is **not** needed to use the `-mmacosx-version-min` option generated by `CMAKE_OSX_DEPLOYMENT_TARGET`.3.7.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16324Problems with usage requirements for `target_link_libraries(<big-shared> ... ...2018-02-20T16:28:56-05:00Ruslan Baratovx@ruslo.devProblems with usage requirements for `target_link_libraries(<big-shared> ... <small-static> <small-static>)` configurationHi,
I got problems with usage requirements for next configuration:
* Static libraries `foo_a` and `foo_b`. Library `foo_a` use `FOO_A_VAR1` macro in public headers so `target_compile_definitions(foo_a PUBLIC FOO_A_VAR1)` used.
* Shared...Hi,
I got problems with usage requirements for next configuration:
* Static libraries `foo_a` and `foo_b`. Library `foo_a` use `FOO_A_VAR1` macro in public headers so `target_compile_definitions(foo_a PUBLIC FOO_A_VAR1)` used.
* Shared library `foo_all` use methods from `foo_a` and `foo_b`. This is the main library for users (public API).
* Executable `foo_c` which use `foo_all` library.
Everything works fine when all targets `foo_a`, `foo_b`, `foo_all` installed and `target_link_libraries` used with PUBLIC: `target_link_libraries(foo_all PUBLIC foo_a foo_b)`.
However since we need only one `foo_all` library, I want to avoid installing `foo_a` and `foo_b`. There are some redundancy indeed, code from `foo_a`:
```
> objdump -dC /.../lib/libfoo_a.a | grep -A2 'foo::a::A::a()>'
0000000000000000 <foo::a::A::a()>:
0: b8 42 00 00 00 mov $0x42,%eax
5: c3 retq
```
Already present in `foo_all`:
```
> objdump -dC /.../lib/libfoo_all.so | grep -A2 'foo::a::A::a()>'
00000000000007d0 <foo::a::A::a()>:
7d0: b8 42 00 00 00 mov $0x42,%eax
7d5: c3 retq
```
But when I remove code for installing `foo_a`/`foo_b` I got next errors:
```
CMake Error: install(EXPORT "fooTargets" ...) includes target "foo_all" which requires target "foo_a" that is not in the export set.
CMake Error: install(EXPORT "fooTargets" ...) includes target "foo_all" which requires target "foo_b" that is not in the export set.
```
Because we use PUBLIC in `target_link_libraries(foo_all PUBLIC foo_a foo_b)` hence need `foo_a`/`foo_b`. I can't change it to `target_link_libraries(foo_all PRIVATE foo_a foo_b)` because in this case usage requirement of `foo_a` will be broken - we need `FOO_A_VAR1` defined for executable `foo_c`:
```
/usr/bin/g++ ... -c /.../app/foo/c/main.cpp
In file included from /.../lib/foo/all/all.hpp:4:0,
from /.../app/foo/c/main.cpp:1:
/.../lib/foo/a/A.hpp:5:3: error: #error "FOO_A_VAR1 not defined!"
# error "FOO_A_VAR1 not defined!"
```
The original code was not written by me. I personally think that it make sense to collect all sources from `foo_a`/`foo_b` and use them in `foo_all` without intermediate static libraries. However this example shows the flaw in usage requirements system which as far as I understand assume that definitions and link libraries always tied to each other. As example shows it may not be true, dependent definitions and dependent libraries can be used separately.
Example can be found here: https://github.com/forexample/big-shared
Let me know if I'm missing something.