CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-02-15T07:29:09-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/18923VS: Unable to choose 8.1 SDK version in VS 152019-02-15T07:29:09-05:00Dedmen MillerVS: Unable to choose 8.1 SDK version in VS 15It seems like it's currently impossible to make CMake use the Windows 8.1 SDK when building on a Windows 10 host system with VS14 or above.
I tried forcing CMake to use the 8.1 SDK by doing
```
if (${CMAKE_HOST_SYSTEM_NAME} STREQUAL "Wi...It seems like it's currently impossible to make CMake use the Windows 8.1 SDK when building on a Windows 10 host system with VS14 or above.
I tried forcing CMake to use the 8.1 SDK by doing
```
if (${CMAKE_HOST_SYSTEM_NAME} STREQUAL "Windows")
set (CMAKE_SYSTEM_VERSION 8.1 CACHE TYPE INTERNAL FORCE) #Force 8.1 SDK, to keep it compatible with win7
endif()
```
I tried `6.3`, `7`, `8`, `8.1` values and each one always chose the latest installed SDK version being `10.0.17763.0`
The code `cmGlobalVisualStudio14Generator::GetWindows10SDKVersion` only checks for windows 10 SDK versions.
The code compares the version here
https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGlobalVisualStudio14Generator.cxx#L313 <br>
And correctly has "8.1" in the `this->SystemVersion` but because the windows 8.1 SDK is not inside `sdks` it will never be checked and it will fallback to the latest SDK on L320.
If I just cheat and insert a `sdks.emplace_back("8.1");` in L307, then it correctly creates a vcxproj with Windows SDK version set to 8.1 exactly like I need.
I have also tried to do
`set(CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION "8.1")`
and
`set (CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION 8.1 CACHE TYPE INTERNAL FORCE)`
before/after the `project()` definition, and also at the far end of my CMakeList.<br>
This caused no effect (project is built with `10.0.17763.0` SDK).
I need to build applications that have to be backwards compatible till windows 7, the latest windows 10 SDK however links the dll/executable against functions in windows libraries that simply don't exist on win 7/8.
Seems like I'm not alone with that problem. https://social.msdn.microsoft.com/Forums/en-US/fcbf7b3f-9548-47ea-bb38-03d10eb6bfbb/how-to-select-the-windows-sdk-81-when-using-cmake-in-visual-studio-2017?forum=visualstudiogeneral3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18919PGI Compiler Feature Support Regression [3.14.0-RC1]2019-02-15T07:19:55-05:00Robert MaynardPGI Compiler Feature Support Regression [3.14.0-RC1]Starting in 3.14.0-RC1 the C++ language feature detection for the PGI compiler is failing. Also tried out the IBM xlC compiler which has the same pattern of only meta language features and it works.
Test code:
```cmake
cmake_minimum_re...Starting in 3.14.0-RC1 the C++ language feature detection for the PGI compiler is failing. Also tried out the IBM xlC compiler which has the same pattern of only meta language features and it works.
Test code:
```cmake
cmake_minimum_required(VERSION 3.9)
project(scorch)
add_library(foo main.cxx)
target_compile_features(foo PUBLIC cxx_std_11)
```
CMake Build Output:
```
[atkins3@gcc2-power8 build]$ rm -rf CMakeFiles/
[atkins3@gcc2-power8 build]$ rm CMakeCache.txt
[atkins3@gcc2-power8 build]$ CXX=/opt/cfarm/pgi/linuxpower/18.10/bin/pgc++ ~/users/robert.maynard/cmake/build/bin/cmake ../
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is PGI 18.10.1
-- 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
-- Check for working CXX compiler: /opt/cfarm/pgi/linuxpower/18.10/bin/pgc++
-- Check for working CXX compiler: /opt/cfarm/pgi/linuxpower/18.10/bin/pgc++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
CMake Error at CMakeLists.txt:4 (target_compile_features):
target_compile_features no known features for CXX compiler
"PGI"
version 18.10.1.
-- Configuring incomplete, errors occurred!
See also "/home/atkins3/users/robert.maynard/scorch/build/CMakeFiles/CMakeOutput.log".
See also "/home/atkins3/users/robert.maynard/scorch/build/CMakeFiles/CMakeError.log".
```3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18914REGRESSION: 3.14.0-rc1 Fortran: no "-I/usr/include" on Ubuntu 18.042019-03-28T13:21:00-04:00scivisionREGRESSION: 3.14.0-rc1 Fortran: no "-I/usr/include" on Ubuntu 18.04I have noticed switching from CMake 3.13.4 to 3.14.0-rc1 (downloaded Linux binary from Kitware) that `-I/usr/include` is no longer added at the build stage, making numerous Fortran programs that worked with 3.13.4 suddenly stop compiling...I have noticed switching from CMake 3.13.4 to 3.14.0-rc1 (downloaded Linux binary from Kitware) that `-I/usr/include` is no longer added at the build stage, making numerous Fortran programs that worked with 3.13.4 suddenly stop compiling with missing headers error from gfortran. This is when `/usr/include` is explicitly specified with `target_include_directories()`
This is for system Gfortran 7 with Ubuntu system libraries.
**NOTE: Switching back to CMake 3.13.4 (downloaded from Kitware Github release) fixes this issue**, so it seems to be a Cmake 3.14.0-rc1 issue
also broken: Cmake-dev version 3.13.20190204-g9f527
I didn't try other dev versions.
Because it requires a Fortran library with headers in /usr/include, not so many libraries have that, but `libnetcdff-dev` does, for example: https://github.com/scivision/ncar-glow
Libs that have Fortran headers deeper under /usr/include work. For example /usr/include/mylib/mylib.h works, but /usr/include/mylib.h does not work.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18911CUDA: Device Linking doesn't properly drop frameworks2019-03-01T09:08:59-05:00Robert MaynardCUDA: Device Linking doesn't properly drop frameworksWhen building a CUDA target that has device linking any frameworks that are listed will be passed to the device linker. This causes a malformed device link line:
```cmake
cmake_minimum_required(VERSION 3.13 FATAL_ERROR)
project(framewo...When building a CUDA target that has device linking any frameworks that are listed will be passed to the device linker. This causes a malformed device link line:
```cmake
cmake_minimum_required(VERSION 3.13 FATAL_ERROR)
project(framework_cuda_linking LANGUAGES CXX CUDA)
find_package(OpenGL REQUIRED)
add_executable(example test.cu)
target_compile_features(example PUBLIC cxx_std_11)
set_target_properties( example
PROPERTIES CUDA_SEPARABLE_COMPILATION ON
)
message(STATUS "OPENGL_LIBRARIES: ${OPENGL_LIBRARIES}")
target_link_libraries(example ${OPENGL_LIBRARIES})
```
Causes the following device link line to be generated:
```
nvcc -Xcompiler=-fPIC -shared -dlink CMakeFiles/.../test.cu.o -o CMakeFiles/.../cmake_device_link.o OpenGL
```
If you use the `OpenGL::GL` target the following issue doesn't occur.3.14.0Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/18908FindBoost does not find Boost 1.69.0 built with --layout=tagged2019-02-19T07:53:51-05:00Braden McDanielFindBoost does not find Boost 1.69.0 built with --layout=taggedFindBoost (in CMake 3.14.0-rc1, but I believe previous versions, as well) doesn't appear to be looking for the library names emitted from the Boost 1.69.0 build when building with `--layout=tagged`.
This produces, for example, library n...FindBoost (in CMake 3.14.0-rc1, but I believe previous versions, as well) doesn't appear to be looking for the library names emitted from the Boost 1.69.0 build when building with `--layout=tagged`.
This produces, for example, library names of the form
```
boost_system-mt-x64
boost_system-mt-d-x64
```
I am using FindBoost with these settings:
```
set(Boost_USE_STATIC_LIBS true)
set(Boost_USE_MULTITHREADED true)
set(Boost_MINIMUM_VERSION "1.64")
set(Boost_ADDITIONAL_VERSIONS "1.64.0" "1.64")
set(Boost_NO_BOOST_CMAKE ON)
set(Boost_NO_SYSTEM_PATHS ON)
set(Boost_ARCHITECTURE "-x64")
set(Boost_DEBUG ON)
```
...which results in the following search list being emitted:
```
Searching for SYSTEM_LIBRARY_RELEASE: boost_system-gcc7-mt-x64-1_69;boost_system-gcc7-mt;boost_system-mt-x64-1_69;boost_system-mt;boost_system-mt;boost_system
Searching for SYSTEM_LIBRARY_DEBUG: boost_system-gcc7-mt-d-x64-1_69;boost_system-gcc7-mt-d;boost_system-mt-d-x64-1_69;boost_system-mt-d;boost_system-mt;boost_system
```3.14.0https://gitlab.kitware.com/cmake/cmake/-/issues/18906Asterisk in front of default generator breaks CMake.js2019-02-14T09:20:33-05:00Gregor JasnyAsterisk in front of default generator breaks CMake.jsHello,
cmake.js calls `cmake --help` to parse the available generators. Recently an `*` was added to show the default one:
```
The following generators are available on this platform (* marks default):
Visual Studio 16 2019 = ...Hello,
cmake.js calls `cmake --help` to parse the available generators. Recently an `*` was added to show the default one:
```
The following generators are available on this platform (* marks default):
Visual Studio 16 2019 = Generates Visual Studio 2019 project files.
Use -A option to specify architecture.
* Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
Optional [arch] can be "Win64" or "IA64".
Visual Studio 9 2008 [arch] = Generates Visual Studio 2008 project files.
Optional [arch] can be "Win64" or "IA64".
```
Would you consider moving the `*` behind the `=` to unbreak parsing?
Like
```
Visual Studio 16 2019 = Generates Visual Studio 2019 project files.
Use -A option to specify architecture.
Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files. [default]
Optional [arch] can be "Win64" or "ARM".
```
Code in question: https://github.com/cmake-js/cmake-js/blob/v3.6.0/lib/es6/cMake.js#L68
Thanks,
Gregor3.14.0https://gitlab.kitware.com/cmake/cmake/-/issues/18904CMake 3.14.0-rc1 fails to detect VS2017 when reqesting 64bit compiler2023-03-13T14:02:07-04:00Gregor JasnyCMake 3.14.0-rc1 fails to detect VS2017 when reqesting 64bit compilerHello,
when configuring a minimal CMake project with 3.13.2 it works as expected:
```
C:\git\localbuilds\ExternalLibs\CMake\3.13.2\Tools_Windows\bin\cmake.exe -G"Visual Studio 15 2017" -T host=x64 ..
-- Selecting Windows SDK version 1...Hello,
when configuring a minimal CMake project with 3.13.2 it works as expected:
```
C:\git\localbuilds\ExternalLibs\CMake\3.13.2\Tools_Windows\bin\cmake.exe -G"Visual Studio 15 2017" -T host=x64 ..
-- Selecting Windows SDK version 10.0.16299.0 to target Windows 10.0.17763.
-- The C compiler identification is MSVC 19.16.27026.1
-- The CXX compiler identification is MSVC 19.16.27026.1
...
```
but with CMake 3.14.0-rc1 compiler detection fails:
```
C:\git\localbuilds\ExternalLibs\CMake\3.14.0-rc1\Tools_Windows\bin\cmake.exe -G"Visual Studio 15 2017" -T host=x64 ..
-- Selecting Windows SDK version 10.0.16299.0 to target Windows 10.0.17763.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
```
The `CMakeError.log` shows the following:
```
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:
The output was:
1
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 11.02.2019 09:05:31.
Project "C:\git\cmake-vs-bug\_build\CMakeFiles\3.14.0-rc1\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug\".
Creating directory "Debug\CompilerIdC.tlog\".
InitializeBuildStatus:
Creating "Debug\CompilerIdC.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\HostX64\x86\CL.exe /c /nologo /W0 /WX- /diagnostics:classic /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc141.pdb" /Gd /TC /analyze- /FC /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
Link:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\HostX64\x86\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X86 /SAFESEH Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1104: cannot open file 'ucrtd.lib' [C:\git\cmake-vs-bug\_build\CMakeFiles\3.14.0-rc1\CompilerIdC\CompilerIdC.vcxproj]
Done Building Project "C:\git\cmake-vs-bug\_build\CMakeFiles\3.14.0-rc1\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED.
Build FAILED.
```
![Attached](/uploads/dabdd70959fbcd174ebfc7839ff7e61c/vsinstaller.png) you'll find a screenshot of the installed workloads.
Thanks,
Gregor3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18898VS: Remove hack specific to VS 2019 Preview 2 and 32019-03-01T09:07:32-05:00Brad KingVS: Remove hack specific to VS 2019 Preview 2 and 3[This code](https://gitlab.kitware.com/cmake/cmake/blob/v3.14.0-rc1/Source/cmVSSetupHelper.cxx#L193-200) was added because VS 2019 preview 2 stopped providing `Microsoft.VCToolsVersion.default.txt`. MS plans to restore that file before ...[This code](https://gitlab.kitware.com/cmake/cmake/blob/v3.14.0-rc1/Source/cmVSSetupHelper.cxx#L193-200) was added because VS 2019 preview 2 stopped providing `Microsoft.VCToolsVersion.default.txt`. MS plans to restore that file before the final VS 2019 release. Once that release is out we can drop the workaround.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18896add_subdirectory: EXCLUDE_FROM_ALL breaks INTERFACE libraries2019-02-11T07:44:46-05:00Brad Kingadd_subdirectory: EXCLUDE_FROM_ALL breaks INTERFACE libraries```console
$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(Example NONE)
add_subdirectory(sub EXCLUDE_FROM_ALL)
$ cat ../sub/CMakeLists.txt
add_library(iface INTERFACE)
$ cmake ..
CMake Error at sub/CMakeLists.txt:...```console
$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(Example NONE)
add_subdirectory(sub EXCLUDE_FROM_ALL)
$ cat ../sub/CMakeLists.txt
add_library(iface INTERFACE)
$ cmake ..
CMake Error at sub/CMakeLists.txt:1 (add_library):
INTERFACE_LIBRARY targets may only have whitelisted properties. The
property "EXCLUDE_FROM_ALL" is not allowed.
```3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18894Applying GENEX_EVAL to property that already contains GENEX_EVAL2019-02-13T08:40:47-05:00yrHeTaTeJlbApplying GENEX_EVAL to property that already contains GENEX_EVALThere is following code:
```
cmake_minimum_required(VERSION 3.12)
project(test CXX)
add_executable(foo foo.cpp)
set_target_properties(
foo
PROPERTIES
"a" "$<GENEX_EVAL:$<TARGET_PROPERTY:b>>"
"b" "$<GENEX_EVAL:$<TARGET_PROPE...There is following code:
```
cmake_minimum_required(VERSION 3.12)
project(test CXX)
add_executable(foo foo.cpp)
set_target_properties(
foo
PROPERTIES
"a" "$<GENEX_EVAL:$<TARGET_PROPERTY:b>>"
"b" "$<GENEX_EVAL:$<TARGET_PROPERTY:c>>"
"c" "$<GENEX_EVAL:$<TARGET_PROPERTY:d>>"
"d" "$<1:macarena>"
)
target_compile_options(foo PRIVATE "$<TARGET_GENEX_EVAL:foo,$<TARGET_PROPERTY:foo,a>>")
```
`a` reads `b`, `b` reads `c`, `c` reads `d`, `d` have to be expanded as `macarena`.
I expect compilation error due to unknown compiler option `macarena`.
But:
* cmake 3.13.1 on Linux(Centos 7) just crashes.
* cmake 3.12.4 on Windows 10 produces following error:
```
CMake Error at CMakeLists.txt:14 (target_compile_options):
Error evaluating generator expression:
$<GENEX_EVAL:$<TARGET_PROPERTY:c>>
Dependency loop found.
CMake Error at CMakeLists.txt:14 (target_compile_options):
Loop step 1
$<GENEX_EVAL:$<TARGET_PROPERTY:b>>
CMake Error at CMakeLists.txt:14 (target_compile_options):
Loop step 2
$<TARGET_GENEX_EVAL:foo,$<TARGET_PROPERTY:foo,a>>
CMake Error:
Loop step 3
$<GENEX_EVAL:$<TARGET_PROPERTY:c>>
```
Probably if I update cmake on Windows I get crash as well.
Am I doing something wrong or this is cmake bug?
UPD:
I believe that problem places are [`assert` in `TargetPropertyNode::Evaluate`](https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGeneratorExpressionNode.cxx#L1321) and [and `if` in `cmGeneratorExpressionDAGChecker::CheckGraph()`](https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmGeneratorExpressionDAGChecker.cxx#L138). If I remove them, everything works as expected.
3.14.0Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/18878Cannot disable warnings with CSharp / VS generator.2019-02-07T06:42:35-05:00Wil StarkCannot disable warnings with CSharp / VS generator.There appears to be no way to disable warnings. E.g. I expect that something like:
```cmake
target_compile_options(${TARGET_NAME} PRIVATE "/nowarn:101,303" )
```
-or-
```cmake
set(CMAKE_CSharp_FLAGS "${CMAKE_CSharp_FLAGS} /nowarn:101,30...There appears to be no way to disable warnings. E.g. I expect that something like:
```cmake
target_compile_options(${TARGET_NAME} PRIVATE "/nowarn:101,303" )
```
-or-
```cmake
set(CMAKE_CSharp_FLAGS "${CMAKE_CSharp_FLAGS} /nowarn:101,303")
```
-or-
```cmake
set(CMAKE_CSharp_FLAGS_DEBUG "${CMAKE_CSharp_FLAGS_DEBUG} /nowarn:101,303")
```
will result in a C# command line including "/nowarn:101,303". (Even better would be if the VS IDE showed those warning disabled.)
But CMake puts this information into the <AdditionalOptions> node, where VS appears to ignore it.
NOTE: There are other settings as well that seem to be in a similar predicament, e.g. 'Platform' defaults to x86, and I can't get it set to 'AnyCPU' (or any other value) as it is handled similarly.
It looks like the cmIDEOptions table for VS12_CSharp and cmIDEOptions code needs an update.3.14.0https://gitlab.kitware.com/cmake/cmake/-/issues/18871Xcode 10.2 no longer supports Swift 3 causing compiler test to fail2019-02-06T10:12:40-05:00GentoliXcode 10.2 no longer supports Swift 3 causing compiler test to failXcode 10.2 comes with Swift 5.\
The test build project generated defaults to Swift 3.0.\
This cannot be override by `-DCMAKE_XCODE_ATTRIBUTE_SWIFT_VERSION=5.0` or `export SWIFT_VERSION=5.0`.
Links:\
[Swift 5 Release Notes](https://deve...Xcode 10.2 comes with Swift 5.\
The test build project generated defaults to Swift 3.0.\
This cannot be override by `-DCMAKE_XCODE_ATTRIBUTE_SWIFT_VERSION=5.0` or `export SWIFT_VERSION=5.0`.
Links:\
[Swift 5 Release Notes](https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_beta_release_notes/swift_5_release_notes_for_xcode_10_2_beta?language=objc)3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18855Ninja: Use depfile with Intel Compiler for Windows2019-02-06T10:12:37-05:00Brad KingNinja: Use depfile with Intel Compiler for WindowsWith [ninja PR 1039](https://github.com/ninja-build/ninja/pull/1039) merged, Ninja 1.9 will support the depfiles produced by the Intel Compiler for Windows. This means that with a sufficiently new Ninja, CMake's generator can switch to ...With [ninja PR 1039](https://github.com/ninja-build/ninja/pull/1039) merged, Ninja 1.9 will support the depfiles produced by the Intel Compiler for Windows. This means that with a sufficiently new Ninja, CMake's generator can switch to them over the showIncludes approach.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18841Mapping of /experimental:module flag to MSBuild XML in Visual Studio generator2019-02-08T19:02:58-05:00David HunterMapping of /experimental:module flag to MSBuild XML in Visual Studio generatorAs of VS2019 the compiler option /experimental:module maps to the MSBuild XML <EnableModules>true</EnableModules> in the <ClCompile> section of the project file.
My understanding is that CMake has a bunch of such "known" mappings when it...As of VS2019 the compiler option /experimental:module maps to the MSBuild XML <EnableModules>true</EnableModules> in the <ClCompile> section of the project file.
My understanding is that CMake has a bunch of such "known" mappings when it generates VS project files so it would great if this one was added.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18834VS: Add support for Visual Studio 2019 Preview 22019-01-28T08:07:31-05:00Ian DayVS: Add support for Visual Studio 2019 Preview 2Preview 2 seems to have killed the new generator. It can't find the VS install. Looks like they changed a filename:
`C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Auxiliary/Build/Microsoft.VCToolsVersion.default.txt`
be...Preview 2 seems to have killed the new generator. It can't find the VS install. Looks like they changed a filename:
`C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Auxiliary/Build/Microsoft.VCToolsVersion.default.txt`
became
`C:/Program Files (x86)/Microsoft Visual Studio/2019/Preview/VC/Auxiliary/Build/Microsoft.VCToolsVersion.v142.default.txt`
And as commented in the source, the toolset is now v142.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18819Segfault when generating tests with CROSSCOMPILING_EMULATOR set to empty string2019-01-22T09:41:26-05:00Kyle EdwardsSegfault when generating tests with CROSSCOMPILING_EMULATOR set to empty stringMinimum reproducible example:
```cmake
cmake_minimum_required(VERSION 3.12)
project(test C)
enable_testing()
file(WRITE "${PROJECT_BINARY_DIR}/main.c" "int main(){return 0;}")
add_executable(main "${PROJECT_BINARY_DIR}/main.c")
set_pr...Minimum reproducible example:
```cmake
cmake_minimum_required(VERSION 3.12)
project(test C)
enable_testing()
file(WRITE "${PROJECT_BINARY_DIR}/main.c" "int main(){return 0;}")
add_executable(main "${PROJECT_BINARY_DIR}/main.c")
set_property(TARGET main PROPERTY CROSSCOMPILING_EMULATOR "")
add_test(NAME main COMMAND main)
```
Running CMake on this causes a segfault.
The offending code is in `Source/cmTestGenerator.cxx` starting at line 90:
```c++
// Prepend with the emulator when cross compiling if required.
const char* emulator = target->GetProperty("CROSSCOMPILING_EMULATOR");
if (emulator != nullptr) {
std::vector<std::string> emulatorWithArgs;
cmSystemTools::ExpandListArgument(emulator, emulatorWithArgs);
std::string emulatorExe(emulatorWithArgs[0]); // <-- BAD - assumes emulatorWithArgs is not empty
cmSystemTools::ConvertToUnixSlashes(emulatorExe);
os << cmOutputConverter::EscapeForCMake(emulatorExe) << " ";
for (std::vector<std::string>::const_iterator ei =
emulatorWithArgs.begin() + 1;
ei != emulatorWithArgs.end(); ++ei) {
os << cmOutputConverter::EscapeForCMake(*ei) << " ";
}
}
```
I will fix this myself when I get in tomorrow.3.14.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/18795CMakeLists.txt can not be added in source_group anymore2019-01-15T13:20:04-05:00Michael SEGURACMakeLists.txt can not be added in source_group anymoreIn the previous version it was possible to add the CMakeLists.txt in the source_group like that:
`source_group("CMake" FILES CMakeLists.txt)`
Since multiple versions, it's not working anymore, in visual studio the CMakeLists.txt is not i...In the previous version it was possible to add the CMakeLists.txt in the source_group like that:
`source_group("CMake" FILES CMakeLists.txt)`
Since multiple versions, it's not working anymore, in visual studio the CMakeLists.txt is not in CMake folder.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18793automoc: build mocs_compilation.cpp.o earlier to improve parallelism2019-01-21T07:53:26-05:00Peter Wupeter@lekensteyn.nlautomoc: build mocs_compilation.cpp.o earlier to improve parallelismWhile investigating the build time, I found that it would waste some time at the end of the build, compiling `moc_compilation.cpp.o` and subsequently linking a single executable. This `moc_compilation.cpp.o` object file is presumably bui...While investigating the build time, I found that it would waste some time at the end of the build, compiling `moc_compilation.cpp.o` and subsequently linking a single executable. This `moc_compilation.cpp.o` object file is presumably built because `AUTOMOC` is on, but takes about eight seconds to build.
See this picture for a full build that measures when the compiler starts and ends, the large bar at the bottom is building `moc_compilation.cpp.o`, in the top right corner is the final executable (which takes about a second to link with lld). Also visible is that ninja runs out of jobs and wastes some time. The vertical lines mark seconds (this build took 175.4 seconds).
![screenshot of build time visualization](/uploads/c3f1c789a16dba967e91068342bc251d/image.png)
I suppose that if this object is built earlier, then jobs could be better distributed, reducing idle and compile times.
This particular object has the following dependency:
```
# ninja -t browse ui/qt/CMakeFiles/qtui.dir/qtui_autogen/mocs_compilation.cpp.o
target is built using rule CXX_COMPILER__qtui of
cmake_object_order_depends_target_qtui (order-only)
ui/qt/qtui_autogen/mocs_compilation.cpp
dependent edges build:
run/wireshark
ui/qt/qtui
```
`qtui` is an object library included with the `wireshark` executable target. Just running `ninja -nvj1 qtui` reveals that the above object is built very late:
```
[216/223] /usr/bin/clang++ ... -o ui/qt/CMakeFiles/qtui.dir/qtui_autogen/mocs_compilation.cpp.o ...
```
Just building this single object (`ninja -nvj1 ui/qt/CMakeFiles/qtui.dir/qtui_autogen/mocs_compilation.cpp.o`) reveals a few dependencies (19 jobs in total):
- lrelease (for translations)
- `cmake -E cmake_autogen`, `cmake -E cmake_autorcc`
My question, is there a way to order the autogen target earlier in the dependency list to ensure that its build is started earlier? The goal is to reduce the idle time and therefore reduce the total build time.3.14.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/18746Fortran submodule support across compilers2019-02-14T10:30:09-05:00scivisionFortran submodule support across compilersFortran `submodule` support is highly welcomed and necessary in CMake.
However, at the moment `submodule` doesn't work for some popular Fortran compilers:
* works: Gfortran, Intel ifort
* broken: Flang, PGI, IBM XL
## submodule interfa...Fortran `submodule` support is highly welcomed and necessary in CMake.
However, at the moment `submodule` doesn't work for some popular Fortran compilers:
* works: Gfortran, Intel ifort
* broken: Flang, PGI, IBM XL
## submodule interface file naming conventions
The CMake source in several places depends on the *de facto* file naming practices of gfortran and ifort.
Unfortunately PGI, Flang and IBM XL chose a different file naming practice.
Here is a table of the file naming conventions for a two-file program with `module demo` and `submodule hi` in separate files:
Compiler | module files | submodule files
-----------|----------------------|----------------
`gfortran` | `demo.mod demo.smod` | `demo@hi.smod`
`flang` | `demo.mod` | `demo-hi.mod`
`pgf90` | `demo.mod` | `demo-hi.mod`
`ifort` | `demo.mod` | `demo@hi.smod`
`xlf2008` | `demo.mod` | `demo_hi.smod`
`ftn` (Cray) | `DEMO.mod` | `HI.mod`
Cray need to use `ftn -em` to expose the .mod files in the filesystem.
## CMake source files needing modification
A quick `grep` indicates that at least this C++ code may need modification to support Fortran `submodule` across compilers:
* Source/cmFortranParserImpl.cxx
* Source/cmDependsFortran.cxx
## What to do?
I would need guidance from the maintainers as if/how to indicate which compiler is being used, to generalize the behavior of the C++ code above.3.14.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18745Cmake does not support llvm-rc on windows2019-02-20T14:59:42-05:00Sevastyan PigarevCmake does not support llvm-rc on windowsI am trying to get rid of all MSVC-related tools and it fails with `rc`:
```
C:\Users\dark\test>cmake -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_LINKER=lld-link -G Ninja -DCMAKE_GENERATOR_RC=llvm-rc -DCMAKE_RC_CO...I am trying to get rid of all MSVC-related tools and it fails with `rc`:
```
C:\Users\dark\test>cmake -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_LINKER=lld-link -G Ninja -DCMAKE_GENERATOR_RC=llvm-rc -DCMAKE_RC_COMPILER=llvm-rc .
-- The C compiler identification is Clang 7.0.1
-- The CXX compiler identification is Clang 7.0.1
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- broken
CMake Error at C:/Program Files/CMake/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"C:/Program Files/LLVM/bin/clang-cl.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/dark/test/CMakeFiles/CMakeTmp
Run Build Command:"C:/ProgramData/chocolatey/bin/ninja.exe" "cmTC_935b2"
[1/2] Building C object CMakeFiles\cmTC_935b2.dir\testCCompiler.c.obj
[2/2] Linking C executable cmTC_935b2.exe
FAILED: cmTC_935b2.exe
cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\cmTC_935b2.dir --manifests -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo CMakeFiles\cmTC_935b2.dir\testCCompiler.c.obj /out:cmTC_935b2.exe /implib:cmTC_935b2.lib /pdb:cmTC_935b2.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
RC Pass 1: command "rc /foCMakeFiles\cmTC_935b2.dir/manifest.res CMakeFiles\cmTC_935b2.dir/manifest.rc" failed (exit code 0) with the following output:
The system cannot find the file specified
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
-- Configuring incomplete, errors occurred!
See also "C:/Users/dark/test/CMakeFiles/CMakeOutput.log".
See also "C:/Users/dark/test/CMakeFiles/CMakeError.log".
```
Cmake seem to completely ignore the command line3.14.0