CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-11-11T10:25:54-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/19920OBJC and OBJCXX not accounted for in try_compile() implementation2019-11-11T10:25:54-05:00Craig ScottOBJC and OBJCXX not accounted for in try_compile() implementationThe implementation in `cmCoreTryCompile.cxx` (and maybe other places) only accounts for C, CXX and CUDA languages. These should also be updated to account for the new OBJC and OBJCXX languages if we expect them to have parity with C and ...The implementation in `cmCoreTryCompile.cxx` (and maybe other places) only accounts for C, CXX and CUDA languages. These should also be updated to account for the new OBJC and OBJCXX languages if we expect them to have parity with C and CXX. Otherwise enabling OBJC and OBJCXX languages could conceivably break previously okay projects.3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19919Missing documentation for various OBJC and OBJCXX language things2019-11-12T09:47:51-05:00Craig ScottMissing documentation for various OBJC and OBJCXX language thingsThe direct support for ObjC and ObjC++ added in !3811 brings with it the ability to specify the language standard. That MR appears to have missed adding documentation for the corresponding target properties `<LANG>_STANDARD`, `<LANG>_STA...The direct support for ObjC and ObjC++ added in !3811 brings with it the ability to specify the language standard. That MR appears to have missed adding documentation for the corresponding target properties `<LANG>_STANDARD`, `<LANG>_STANDARD_REQUIRED` and `<LANG>_EXTENSIONS`, as well as their associated CMake variables.3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19918Building the "package" target fails if CPACK_INSTALL_CMAKE_CONFIGURATIONS con...2019-11-12T08:16:41-05:00Craig ScottBuilding the "package" target fails if CPACK_INSTALL_CMAKE_CONFIGURATIONS contains more than one config!3533 introduced the new `CPACK_INSTALL_CMAKE_CONFIGURATIONS` variable. If it is set to more than one configuration, then building the `package` target from a clean build directory will fail. Here's a minimal project used to reproduce th...!3533 introduced the new `CPACK_INSTALL_CMAKE_CONFIGURATIONS` variable. If it is set to more than one configuration, then building the `package` target from a clean build directory will fail. Here's a minimal project used to reproduce the problem:
```cmake
cmake_minimum_required(VERSION 3.15)
project(MultiConfigInstall)
add_executable(barry main.cpp)
install(TARGETS barry RUNTIME DESTINATION bin/$<CONFIG>)
set(CPACK_GENERATOR ZIP)
set(CPACK_INSTALL_CMAKE_CONFIGURATIONS Debug Release)
include(CPack)
```
Issue the following commands to reproduce the build error using Xcode (MSVC has the same behavior too):
```
# Assuming the build directory doesn't exist yet
mkdir build
cd build
cmake -G Xcode ..
cmake --build . --target package
```
Building the `package` target fails because it only tries to build one configuration (Debug), but then when it invokes `cpack`, the build for the other configuration is missing. If you manually build both targets first, then the package is built successfully and contains both configurations. The `package` target will need to learn to recognise that multiple configurations are needed and build all of the ones listed in `CPACK_INSTALL_CMAKE_CONFIGURATIONS` before it runs `cpack`.
There is also a similar situation for the `clean` target as well which will become more important once the above issue is addressed.
**Ignore the rest of the description below, it is incorrect (kept here only so that the comment history makes sense)**
Doing the same thing with the Visual Studio generator gives no error, but only the Debug configuration is included in the package, even if you manually build both the Debug and Release configurations first. Even if you invoke `cpack -C "Debug;Release"` directly, the package includes either just the Debug configuration or nothing at all (again, even if you manually build both configurations first). Which result I get seems to depend on things I may have done beforehand.
Continuing with Visual Studio, if you run `cpack` without the `-C` option, you get an empty package if you haven't built the Release configuration, or you get just the Release configuration if you've built that configuration. In either case, no errors are raised. The Debug configuration gets completely ignored, despite it being listed in `CPACK_INSTALL_CMAKE_CONFIGURATIONS`. It's possible that there might be different results depending on what steps you've done beforehand.
3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19915CMakeFindBinUtils: add search for dlltool?2019-11-04T10:49:13-05:00jannick0CMakeFindBinUtils: add search for dlltool?Would it be feasible to add the search for `dlltool` in `CMakeFindBinUtils` - or rather somewhere else? If YES:
- Would calling `find_program` as given [here](https://gitlab.kitware.com/cmake/cmake/blob/v3.15.0/Modules/CMakeFindBinUtils...Would it be feasible to add the search for `dlltool` in `CMakeFindBinUtils` - or rather somewhere else? If YES:
- Would calling `find_program` as given [here](https://gitlab.kitware.com/cmake/cmake/blob/v3.15.0/Modules/CMakeFindBinUtils.cmake#L101-105) be sufficient?
- Is a restriction to relevant OS needed - or would the user simply rely on the search result of `find_program`?
Discussion requested to be moved here from a related [PR](https://github.com/Kitware/CMake/pull/331) on github.
Happy to draft a PR based on some guidance as to how and where to insert the dlltool search.
Many thanks.3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19914CTest: Rename PROCESSES test property to RESOURCE_GROUPS2019-11-07T13:11:06-05:00Craig ScottCTest: Rename PROCESSES test property to RESOURCE_GROUPSIn looking at how one might explain to people the new hardware allocation tests feature being introduced in CMake 3.16, I come up against the problem that the new `PROCESSES` test property name is too close to the existing `PROCESSORS` p...In looking at how one might explain to people the new hardware allocation tests feature being introduced in CMake 3.16, I come up against the problem that the new `PROCESSES` test property name is too close to the existing `PROCESSORS` property. When said aloud, they both even sound basically the same. @purpleKarrot [first raised this](https://gitlab.kitware.com/cmake/cmake/merge_requests/3858#note_630983) in the original MR, but now that I'm trying to work out how to explain it to people, I'm much more concerned that we've got the naming wrong on this one.
The feature appears to be motivated by wanting to describe how to allocate resources across multiple processes spawned by the test executable. That might be the main motivation, but I can foresee that this functionality may also make sense even for tests that don't spawn other processes. For example, it could be used to provide more fine grained resource allocation across a set of tests, such as ensuring that a set of memory-intensive tests don't consume all available memory by running too many of them in parallel, but without blocking other tests that don't use much memory and don't need to participate in the resource allocation. There are other scenarios one can up with, but hopefully the issue I'm trying to raise is clear.
I know it is getting late in the 3.16 release cycle, but I'd like to propose that we rename the `PROCESSES` test property to something more aligned with resource allocation rather than processes. For the sake of discussion, I'll put forward `RESOURCE_REQUIREMENTS` as a suggested alternative. We could then also rename the section in the `ctest(1)` manual from `Hardware Allocation` to `Resource Allocation`. I'm mildly concerned that this suggested alternative name still leaves the door open for causing confusion with the `RESOURCE_LOCK` property (something I [already raised](https://gitlab.kitware.com/cmake/cmake/merge_requests/3858#note_631543) during the original MR), but at least the two names are distinct. We already have some documentation highlighting the relationship of this feature to `RESOURCE_LOCK`, maybe we would need to give that a bit more prominence.
I have identified further minor cleanup of the docs for this feature (mostly just typos and minor inaccuracies), but I'll hold off putting up a MR for those until we resolve the above in case there are more substantial docs changes required.3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19909FetchContent: Coredump due to assertion failure when extracting to absolute path2019-11-04T10:34:50-05:00Daan De MeyerFetchContent: Coredump due to assertion failure when extracting to absolute pathCMake version: 3.15.5
OS: Arch Linux
Reproduce:
```cmake
cmake_minimum_required(VERSION 3.15)
project(cmake-fetchcontent-reproduce)
include(FetchContent)
FetchContent_declare(
cmake
URL https://github.com/Kitware/CMake/release...CMake version: 3.15.5
OS: Arch Linux
Reproduce:
```cmake
cmake_minimum_required(VERSION 3.15)
project(cmake-fetchcontent-reproduce)
include(FetchContent)
FetchContent_declare(
cmake
URL https://github.com/Kitware/CMake/releases/download/v3.15.5/cmake-3.15.5-Linux-x86_64.tar.gz
SOURCE_DIR /opt
)
FetchContent_MakeAvailable(cmake)
```3.16.0Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/19892AUTOMOC does not work on Windows if there are files with the same basename as...2019-11-01T06:19:45-04:00ahasselbringAUTOMOC does not work on Windows if there are files with the same basename as the actual headerI encountered a problem on Windows in the current CMake master (as well as the 3.16 release candidate) that was not present in 3.15.4. The symptom was the error message "... includes the moc file ..., but the header ... could not be foun...I encountered a problem on Windows in the current CMake master (as well as the 3.16 release candidate) that was not present in 3.15.4. The symptom was the error message "... includes the moc file ..., but the header ... could not be found in the following directories", while that file certainly existed in the first one of the search directories.
Upon investigation, I found out that [this](https://gitlab.kitware.com/cmake/cmake/commit/51676cf65590f7a9bc3ad247151ee5bdc768eb77#1f4b1a66e91b3ed70b4d7621f4b003abb804bc29_835_819) (or rather [here](https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmQtAutoMocUic.cxx#L1345)) is responsible. Passing a path with a trailing dot to `CollapseFullPath` and further down to `GetCasePathName` leads to `FindFirstFileW` getting called. If, in that directory, another file exists without the `.h` suffix, but in a different case (there are possibly more constellations in which this breaks) that one might be returned by `FindFirstFileW` instead, removing the trailing dot and causing the concatenated file name including the extension to be invalid.
(In my case, it was `qtbuttonpropertybrowser.h` which should have been found and `QtButtonPropertyBrowser` which was actually found)
It looks to me like moving the `CollapseFullPathTS` inside the loop after the concatenation with the extension would fix it, but I do not know whether there are other instances of this problem.3.16.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/19890CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY deprecated but not CMAKE_FIND_PACKAGE_...2019-11-05T07:17:23-05:00Craig ScottCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY deprecated but not CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRYFor CMake 3.16, we've currently left behind one inconsistency regarding the package registries. We've added `CMAKE_FIND_USE_PACKAGE_REGISTRY` as a replacement for `CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` and deprecated the latter, but we...For CMake 3.16, we've currently left behind one inconsistency regarding the package registries. We've added `CMAKE_FIND_USE_PACKAGE_REGISTRY` as a replacement for `CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY` and deprecated the latter, but we haven't done anything about `CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY`. It seems odd to deprecate one but not the other.3.16.0Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/19883FindCurses pulls in -lform rather than -lformw despite CURSES_NEED_WIDE2019-10-29T10:39:48-04:00Nick BlackFindCurses pulls in -lform rather than -lformw despite CURSES_NEED_WIDEFor motivations I don't quite understand, FindCurses.cmake gives you the ncurses forms library just for wanting ncurses (the two ought be distinct modules IMHO, or at least form ought require an explicit request). That wouldn't be a big ...For motivations I don't quite understand, FindCurses.cmake gives you the ncurses forms library just for wanting ncurses (the two ought be distinct modules IMHO, or at least form ought require an explicit request). That wouldn't be a big problem, except when I'm using ncursesw via CURSES_NEED_WIDE, I get regular form (as opposed to formw). This drags in regular libncurses.so (in addition to libncursesw.so), and I lose reliable wide character support:
```
[schwarzgerat](0) $ ldd outcurses-demo | grep ncurses
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007fe568097000)
libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 (0x00007fe567e65000)
[schwarzgerat](0) $ ldd /usr/lib/x86_64-linux-gnu/libform.so
linux-vdso.so.1 (0x00007ffd355d7000)
libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 (0x00007f4824dc0000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f4824d91000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4824bd1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4824bcc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4824e72000)
[schwarzgerat](0) $
```
If I manually link without the spurious `/usr/lib/x86_64-linux-gnu/libform.so`, I only get ncursesw.so, and wide characters work as expected.
I can put a patch together for this quickly (tonight, probably). I suppose it's too late for 3.16?3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19880Swift: Command line builds broken on macOS 10.152021-06-16T08:06:01-04:00Brad KingSwift: Command line builds broken on macOS 10.15Xcode 11 can build Swift binaries targeting macOS 10.15, but when using the command line tools with CMake's Ninja or Makefile generators, linking an executable fails with
```
<unknown>:0: error: unable to load standard library for targe...Xcode 11 can build Swift binaries targeting macOS 10.15, but when using the command line tools with CMake's Ninja or Makefile generators, linking an executable fails with
```
<unknown>:0: error: unable to load standard library for target 'x86_64-apple-macosx10.15'
```
Manually adding the option
```
-sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
```
to the `-emit-executable` command line avoids the problem.3.16.0Saleem AbdulrasoolSaleem Abdulrasoolhttps://gitlab.kitware.com/cmake/cmake/-/issues/19862Suggested documentation tweaks for cmake-generator-expressions2019-10-21T11:19:50-04:00Alan W. IrwinSuggested documentation tweaks for cmake-generator-expressionsThat documentation refers to the **same** logic as in the COMPILE_LANG_AND_ID example, but that previous example includes AppleClang so this example should include that as well as indicated
in the following diff.
~~~
software@merlin> gi...That documentation refers to the **same** logic as in the COMPILE_LANG_AND_ID example, but that previous example includes AppleClang so this example should include that as well as indicated
in the following diff.
~~~
software@merlin> git diff --unified=6
diff --git a/Help/manual/cmake-generator-expressions.7.rst b/Help/manual/cmake-generator-expressions.7.rst
index 6e7f9b5b83..ba9887c62f 100644
--- a/Help/manual/cmake-generator-expressions.7.rst
+++ b/Help/manual/cmake-generator-expressions.7.rst
@@ -208,13 +208,13 @@ Variable Queries
Without the ``COMPILE_LANG_AND_ID`` generator expression the same logic
would be expressed as:
.. code-block:: cmake
target_compile_definitions(myapp
- PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Clang>>:COMPILING_CXX_WITH_CLANG>
+ PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:AppleClang,Clang>>:COMPILING_CXX_WITH_CLANG>
$<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Intel>>:COMPILING_CXX_WITH_INTEL>
$<$<AND:$<COMPILE_LANGUAGE:C>,$<C_COMPILER_ID:Clang>>:COMPILING_C_WITH_CLANG>
)
``$<COMPILE_LANGUAGE:languages>``
``1`` when the language used for compilation unit matches any of the entries
~~~
Elsewhere in the file (I don't bother to express it with a diff this time, but you should get the idea) I also noticed that the following change should be made
cxx_headers include directory for C++ only (compiler id checks elided).
==>
/opt/foo/headers include directory for C++ and CUDA.3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19846install(EXPORT): Breaks when a target is named C or CXX2019-10-17T13:52:06-04:00Brad Kinginstall(EXPORT): Breaks when a target is named C or CXXThe project
```cmake
cmake_minimum_required(VERSION 3.0)
project(ExportC C)
add_library(A a.c)
install(TARGETS A EXPORT foo)
install(EXPORT foo DESTINATION lib/cmake/foo)
export(TARGETS A FILE Export.cmake)
add_executable(C c.c)
```
...The project
```cmake
cmake_minimum_required(VERSION 3.0)
project(ExportC C)
add_library(A a.c)
install(TARGETS A EXPORT foo)
install(EXPORT foo DESTINATION lib/cmake/foo)
export(TARGETS A FILE Export.cmake)
add_executable(C c.c)
```
fails to configure with
```
CMake Error: install(EXPORT "foo" ...) includes target "A" which requires target "C" that is not in any export set.
CMake Error in CMakeLists.txt:
export called with target "A" which requires target "C" that is not in any
export set.
```3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19839PCH: Issue with mixing C and C++ within a target2019-10-17T13:52:55-04:00alcroitoPCH: Issue with mixing C and C++ within a targetIf a target contains both C and C++ sources, and specifies a precompiled header which has a C++ class, CMake will try to build a pch file for the C language, which will obviously fail due to treating the header as C code.
I think it wo...If a target contains both C and C++ sources, and specifies a precompiled header which has a C++ class, CMake will try to build a pch file for the C language, which will obviously fail due to treating the header as C code.
I think it would be useful to either specify what language a pch file is for, or allow skipping some languages.
Sample project attached:
[pch_c_language_issue.zip](/uploads/12e1cc1ee8c44a1d90ee422dabb3086e/pch_c_language_issue.zip)3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19830PCH: precompiled header is not recompiled on modification in makefile generator2019-10-18T08:57:24-04:00Jack GuoPCH: precompiled header is not recompiled on modification in makefile generatorI wanted to try out the new `target_precompile_headers` feature in cmake-3.16.0-rc1 so I made this test project.
However when I tried modifying headers that got precompiled it did not trigger a recompile of the PCH file leading to errors...I wanted to try out the new `target_precompile_headers` feature in cmake-3.16.0-rc1 so I made this test project.
However when I tried modifying headers that got precompiled it did not trigger a recompile of the PCH file leading to errors.
`CMakeLists.txt`
```cmake
cmake_minimum_required(VERSION 3.16)
project(testproject CXX)
set(CMAKE_CXX_STANDARD 17)
add_library(mylib INTERFACE)
target_include_directories(mylib INTERFACE inc)
target_precompile_headers(mylib INTERFACE <mylib/a.h>)
add_executable(test src/main.cpp)
target_link_libraries(test PRIVATE mylib)
```
`src/main.cpp`
```cpp
#include <mylib/a.h>
int main() {
int two = get_2();
return two;
}
```
`inc/mylib/a.h`
```cpp
#pragma once
inline int get_2() {
return 2;
}
```
So the first run of the project worked fine.
```sh
$ mkdir build && cd build
$ cmake ..
-- The CXX compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/guoj/testpch/build
$ make
Scanning dependencies of target test
[ 33%] Building CXX object CMakeFiles/test.dir/CMakeFiles/test.dir/cmake_pch.hxx.gch
[ 66%] Building CXX object CMakeFiles/test.dir/src/main.cpp.o
[100%] Linking CXX executable test
[100%] Built target test
```
After it was built I tried modifying `a.h` so `get_2()` returns 3 instead.
```sh
$ make
Scanning dependencies of target test
[ 33%] Building CXX object CMakeFiles/test.dir/src/main.cpp.o
In file included from /home/guoj/testpch/src/main.cpp:1:0:
/home/guoj/testpch/inc/mylib/a.h: In function ‘int get_2()’:
/home/guoj/testpch/inc/mylib/a.h:3:12: error: redefinition of ‘int get_2()’
inline int get_2() {
^~~~~
In file included from /home/guoj/testpch/build/CMakeFiles/test.dir/CMakeFiles/test.dir/cmake_pch.hxx:5:0,
from <command-line>:0:
/home/guoj/testpch/inc/mylib/a.h:3:12: note: ‘int get_2()’ previously defined here
inline int get_2() {
^~~~~
CMakeFiles/test.dir/build.make:78: recipe for target 'CMakeFiles/test.dir/src/main.cpp.o' failed
make[2]: *** [CMakeFiles/test.dir/src/main.cpp.o] Error 1
CMakeFiles/Makefile2:75: recipe for target 'CMakeFiles/test.dir/all' failed
make[1]: *** [CMakeFiles/test.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
```
As seen in the output, it didn't compile `cmake_pch.hxx.gch` before compiling `main.cpp` like it did the first time even though `cmake_pch.hxx.gch` should depend on `a.h`.
Repeating this test using Ninja instead yields the correct result: modifying `a.h` causes `cmake_pch.hxx.gch` to recompile.
```sh
$ ninja | cat
[1/3] Building CXX object CMakeFiles/test.dir/CMakeFiles/test.dir/cmake_pch.hxx.gch
[2/3] Building CXX object CMakeFiles/test.dir/src/main.cpp.o
[3/3] Linking CXX executable test
```
System Info:
CMake Version: cmake-3.16.0-rc1
OS: Ubuntu 18.04
Compiler: gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.03.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/198273.16.0-rc1 seems to have broken `cmake -C init-cache.cmake`2019-11-01T11:02:12-04:00Tobias Hieta3.16.0-rc1 seems to have broken `cmake -C init-cache.cmake`We rely on this feature to set some variables from a autogenerated initial cache. This seems to not work with 3.16.0-rc1 anymore. I did a small isolated test case for this:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.16 FATAL_ER...We rely on this feature to set some variables from a autogenerated initial cache. This seems to not work with 3.16.0-rc1 anymore. I did a small isolated test case for this:
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.16 FATAL_ERROR)
project(Hello C)
message(STATUS ${HELLO})
```
init-cache.cmake
```
set(HELLO "Foobar" CACHE STRING "")
```
When running `cmake -C ../init-cache.cmake ..` I get the following error:
```
loading initial cache file ../init-cache.cmake
CMake Error: Error processing file: ../init-cache.cmake
```
I tried debug and trace functionality but none of those seems to indicate what goes wrong with the init cache.
I downloaded 3.15.4 and doublechecked and it seems to be working just fine there:
```
> ~/t/cmake-3.15.4-Linux-x86_64/bin/cmake -C ../init-cache.cmake .. loading initial cache file ../init-cache.cmake
-- The C compiler identification is GNU 7.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Foobar
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tobias/b/b
```3.16.0https://gitlab.kitware.com/cmake/cmake/-/issues/19825CMake 3.16 must not apply C++ flags to ObjectiveC files2019-10-12T10:26:18-04:00Gregor JasnyCMake 3.16 must not apply C++ flags to ObjectiveC filesHello,
CMake 3.16.0-rc1 breaks compilation of ObjectiveC files by applying C++ compiler flags:
```cmake
cmake_minimum_required(VERSION 3.15.1 FATAL_ERROR)
project(testcase)
string(APPEND CMAKE_CXX_FLAGS " -std=c++11")
set(CMAKE_CXX_S...Hello,
CMake 3.16.0-rc1 breaks compilation of ObjectiveC files by applying C++ compiler flags:
```cmake
cmake_minimum_required(VERSION 3.15.1 FATAL_ERROR)
project(testcase)
string(APPEND CMAKE_CXX_FLAGS " -std=c++11")
set(CMAKE_CXX_STANDARD 14)
add_library(somelib main.m)
```
This results in the following compiler output:
```
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.14 -std=gnu++14 -MD -MT CMakeFiles/somelib.dir/main.m.o -MF CMakeFiles/somelib.dir/main.m.o.d -o CMakeFiles/somelib.dir/main.m.o -c ../main.m
error: invalid argument '-std=gnu++14' not allowed with 'Objective-C'
```
Thanks,
Gregor3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19791Can target_include_directories capture $<CONFIG> as part of a path?2019-10-07T10:34:55-04:00Kelly (KT) ThompsonCan target_include_directories capture $<CONFIG> as part of a path?Hi,
I am trying to register a directory using `target_include_directories` that has `$<CONFIG>` as one part of the path. For example:
```cmake
target_include_directories( Lib_rng PUBLIC
${SOMETPL_INCLUDE_DIR}
$<BUILD_INTERFACE:$...Hi,
I am trying to register a directory using `target_include_directories` that has `$<CONFIG>` as one part of the path. For example:
```cmake
target_include_directories( Lib_rng PUBLIC
${SOMETPL_INCLUDE_DIR}
$<BUILD_INTERFACE:${PROJECT_BINARY_DIR}>
$<INSTALL_INTERFACE:$<CONFIG>/include> )
```
However, when I export the target to generate `mypackage-config.cmake` and `mypackage-targets.cmake`, the `$<CONFIG>` is escaped in a way that breaks importing this target.
```cmake
# mypackage-targets.cmake
...
set_target_properties(Lib_rng PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "C:/work/vendors64/sometpl-1.0.0/include;\$<CONFIG>/include>"
)
```
What I would like exported is expressed by this diff:
```diff
- INTERFACE_INCLUDE_DIRECTORIES "C:/work/vendors64/sometpl-1.0.0/include;\$<CONFIG>/include>"
+ INTERFACE_INCLUDE_DIRECTORIES "C:/work/vendors64/sometpl-1.0.0/include;${_IMPORT_PREFIX}/$<CONFIG>/include>"
```
Is this even possible? If it is helpful, my `CMAKE_INSTALL_PREFIX` looks like this:
```
.../cmake/
mypackage-config.cmake
mypackage-targets.cmake
...
.../Debug/
include/
lib/
bin/
.../Release
include/
lib/
bin/
...
```
For now, I am creating my own `set_target_properties` written to `mypackage-config.cmake` that replaces the one that CMake is generating, but it seems that I should be able to correctly embed `$<CONFIG>` into the published `INTERFACE_INCLUDE_DIRECTORIES`.3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/19790PCH: Linking a C target to a C++ library breaks PCH2019-10-04T10:14:25-04:00Brad KingPCH: Linking a C target to a C++ library breaks PCHIn this example:
```cmake
add_library(foo foo.cpp)
add_executable(bar bar.c)
target_link_libraries(bar foo)
target_precompile_headers(bar PRIVATE "<stddef.h>")
```
no precompiled header is used for target `bar`. The cause is [this lin...In this example:
```cmake
add_library(foo foo.cpp)
add_executable(bar bar.c)
target_link_libraries(bar foo)
target_precompile_headers(bar PRIVATE "<stddef.h>")
```
no precompiled header is used for target `bar`. The cause is [this line](https://gitlab.kitware.com/cmake/cmake/blob/9649c91f830a6fad5c2f84b90f34af10c2edfa15/Source/cmLocalGenerator.cxx#L2256) that relies on the linker language to decide what language to use for PCH. The linker language can be affected by linked targets and so is not appropriate.3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19786PCH: Issue with regenerating pch file with Clang when changing defines in pro...2019-10-04T10:13:15-04:00alcroitoPCH: Issue with regenerating pch file with Clang when changing defines in projectAttaching project below.
The issue is that when you use Clang + CMake + PCH, and you build once, and then you change the project to add a define, and build again, the build will fail because Clang says the gch file / module file is out ...Attaching project below.
The issue is that when you use Clang + CMake + PCH, and you build once, and then you change the project to add a define, and build again, the build will fail because Clang says the gch file / module file is out of date.
Here is sample error message:
```
fatal error: PCH file '/Volumes/T3/Dev/projects/cmake/pch_rebuild_needed/build/CMakeFiles/myapp.dir/CMakeFiles/myapp.dir/cmake_pch.hxx.gch' is out of date and needs to be rebuilt:
module file out of date
note: imported by '/Volumes/T3/Dev/projects/cmake/pch_rebuild_needed/build/CMakeFiles/myapp.dir/CMakeFiles/myapp.dir/cmake_pch.hxx.gch'
1 error generated.
```
Note that this seems to be a bug in clang. If you try to invoke the compiler to generate a gch file with the exact same command line twice, it will create an invalid gch file, and on the third time it will even complain that the gch file can't be created.
The same does not happen with GCC / MSVC.
Tested the issue to happen with Clang 8.0.1 and AppleClang 10.0.1 (XCode 10.2).
It looks like the issue is somehow connected to the fact that both the header file and the compiled artifact are in the same directory.
I think the fix / workaround would be to always remove the gch file before trying to compile it.
Inline project:
```cmake
cmake_minimum_required(VERSION 3.15)
project(precompile_header_issue VERSION 0.1 LANGUAGES CXX)
add_executable(myapp main.cpp header.cpp)
target_include_directories(myapp PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
target_precompile_headers(myapp PRIVATE header.h)
# First build with this commented.
# Then build with this uncommented.
#target_compile_definitions(myapp PRIVATE foo)
```
```
// main.cpp
#include "header.h"
int main() {return blob();}
```
```
// header.h
#ifndef BLOB
#define BLOB
int blob();
#endif
// header.cpp
int blob() { return 2;}
```
[archive.zip](/uploads/d49631c609c17a284955f3c3f32b163b/archive.zip)3.16.0Cristian AdamCristian Adamhttps://gitlab.kitware.com/cmake/cmake/-/issues/19774Ninja generator does not create symlinks with transitive dependency through O...2019-10-02T07:57:30-04:00jheydebrandNinja generator does not create symlinks with transitive dependency through OBJECT libraryWhen using the `Ninja` generator and building a target the transitively depends on a shared library with `SOVERSION` and `VERSION` information the required symlinks to `*.so.<major>.<minor>.<patch>` are not created under some circumstanc...When using the `Ninja` generator and building a target the transitively depends on a shared library with `SOVERSION` and `VERSION` information the required symlinks to `*.so.<major>.<minor>.<patch>` are not created under some circumstances.
Reproduction example:
```
$ cat a.cpp
extern "C" int ext_a() { return 23; }
```
```
$ cat b.cpp
extern "C" int ext_a();
int main() {return ext_a();}
```
```
$ cat c.cpp
//empty
```
```
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.15.0)
project(sonamerepro C CXX)
add_library(A SHARED a.cpp)
set_target_properties(A PROPERTIES SOVERSION 0 VERSION 0.0.0)
add_library(B OBJECT b.cpp)
target_link_libraries(B PUBLIC A)
add_executable(C c.cpp)
target_link_libraries(C PRIVATE B)
```
```
$ cmake --version
cmake version 3.15.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```
The resulting executable `C` has a `NEEDED` entry which refers to `libA.so.0` (see `readelf -a C | grep NEEDED`).
* When target `B` is an `OBJECT` library the build `ninja C` will not create the necessary symlinks.
* When building `ninja A`, the symlinks are created.
* When changing the target type of `B` to `SHARED`, the symlinks are created as expected during `ninja C`.
When using the `Unix Makefiles` generator, the symlinks are created in either case.3.16.0Brad KingBrad King