CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-10-13T13:17:55-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16551CTest ignores the test exit code when PASS_REGULAR_EXPRESSION is set and matched2017-10-13T13:17:55-04:00Sylvain JoubertCTest ignores the test exit code when PASS_REGULAR_EXPRESSION is set and matchedWhen using the `PASS_REGULAR_EXPRESSION` property on a test, if that regex is matched on the output, `ctest` ignores the test exit code and will report a passed test even when the test's exit code is non-zero.
Here is a reduced test cas...When using the `PASS_REGULAR_EXPRESSION` property on a test, if that regex is matched on the output, `ctest` ignores the test exit code and will report a passed test even when the test's exit code is non-zero.
Here is a reduced test case:
```cmake
cmake_minimum_required(VERSION 3.0)
project(ExitCodeVsPassRegex)
include(CTest)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/test_script.cmake "
message(expected_output)
message(FATAL_ERROR non_zero_exit_code)
")
add_test(ExpectedFail ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/test_script.cmake)
add_test(ShouldFail ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/test_script.cmake)
set_tests_properties(ShouldFail PROPERTIES PASS_REGULAR_EXPRESSION "expected_output")
```
```
$ ctest
Test project /home/sylvain/test/cmtest/build
Start 1: ExpectedFail
1/2 Test #1: ExpectedFail .....................***Failed 0.01 sec
Start 2: ShouldFail
2/2 Test #2: ShouldFail ....................... Passed 0.01 sec
50% tests passed, 1 tests failed out of 2
Total Test time (real) = 0.02 sec
The following tests FAILED:
1 - ExpectedFail (Failed)
Errors while running CTest
```https://gitlab.kitware.com/cmake/cmake/-/issues/16550The test RunCMake.try_compile fails for Visual Studio 2012 builds2017-10-13T13:17:55-04:00Michael StürmerThe test RunCMake.try_compile fails for Visual Studio 2012 buildsBuilding CMake on Windows 7 64bit, using CMake 3.7.1 for building, built latest revision (aff368bb8456694e2550e2f69451456728ab31eb)
Sorry, I don't understand where this error comes from so I cannot provide a hint.
I tested it on severa...Building CMake on Windows 7 64bit, using CMake 3.7.1 for building, built latest revision (aff368bb8456694e2550e2f69451456728ab31eb)
Sorry, I don't understand where this error comes from so I cannot provide a hint.
I tested it on several machines with 32bit and 64bit builds, no success.
Visual Studio 2010, 2013 and 2015 run fine.
Here is the Logfile content:
```
Test Name: 354: RunCMake.try_compile
Test FullName: RunCMake.try_compile
Test Source: C:\cmake\Tests\RunCMake\CTestTestfile.cmake : line 976
Test Outcome: Failed
Test Duration: 0:00:32.7
Result Message:
-- CopyFileErrorNoCopyFile - PASSED
-- NoArgs - PASSED
-- OneArg - PASSED
-- TwoArgs - PASSED
-- NoCopyFile - PASSED
-- NoCopyFile2 - PASSED
-- NoCopyFileError - PASSED
-- NoOutputVariable - PASSED
-- NoOutputVariable2 - PASSED
-- NoSources - PASSED
-- BadLinkLibraries - PASSED
-- BadSources1 - PASSED
-- BadSources2 - PASSED
-- NonSourceCopyFile - PASSED
-- NonSourceCompileDefinitions - PASSED
-- PlatformVariables - PASSED
-- WarnDeprecated - PASSED
-- TargetTypeExe - PASSED
-- TargetTypeInvalid - PASSED
-- TargetTypeStatic - PASSED
-- CxxStandardNoDefault - PASSED
-- CMP0056 - PASSED
CMake Error at E:/cmake_orig/Tests/RunCMake/RunCMake.cmake:132 (message):
CMP0066 - FAILED:
Result is [1], not [0].
stdout does not match that expected.
stderr does not match that expected.
Expected stdout to match:
expect-out> -- try_compile with CMP0066 WARN-default worked as expected
expect-out> -- try_compile with CMP0066 WARN-enabled worked as expected
expect-out> -- try_compile with CMP0066 OLD worked as expected
expect-out> -- try_compile with CMP0066 NEW worked as expected
Actual stdout:
actual-out> Not searching for unused variables given on the command line.
actual-out> -- The C compiler identification is MSVC 17.0.61030.0
actual-out> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/cl.exe
actual-out> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/cl.exe -- works
actual-out> -- Detecting C compiler ABI info
actual-out> -- Detecting C compiler ABI info - done
actual-out> -- try_compile with CMP0066 WARN-default worked as expected
actual-out> -- try_compile with CMP0066 WARN-enabled worked as expected
actual-out> -- try_compile with CMP0066 OLD worked as expected
actual-out> -- Configuring incomplete, errors occurred!
actual-out> See also "C:/cmake/Tests/RunCMake/try_compile/CMP0066-build/CMakeFiles/CMakeOutput.log".
Expected stderr to match:
expect-err> before try_compile with CMP0066 WARN-default
expect-err> after try_compile with CMP0066 WARN-default
expect-err> *
expect-err> CMake Warning \(dev\) at CMP0066.cmake:[0-9]+ \(try_compile\):
expect-err> Policy CMP0066 is not set: Honor per-config flags in try_compile\(\)
expect-err> source-file signature. Run "cmake --help-policy CMP0066" for policy
expect-err> details. Use the cmake_policy command to set the policy and suppress this
expect-err> warning.
expect-err>
expect-err> For compatibility with older versions of CMake, try_compile is not honoring
expect-err> caller config-specific compiler flags \(e.g. CMAKE_C_FLAGS_DEBUG\) in the
expect-err> test project.
expect-err> Call Stack \(most recent call first\):
expect-err> CMakeLists.txt:[0-9]+ \(include\)
expect-err> This warning is for project developers. Use -Wno-dev to suppress it.$
Actual stderr:
actual-err> before try_compile with CMP0066 WARN-default
actual-err> after try_compile with CMP0066 WARN-default
actual-err> CMake Warning (dev) at CMP0066.cmake:21 (try_compile):
actual-err> Policy CMP0066 is not set: Honor per-config flags in try_compile()
actual-err> source-file signature. Run "cmake --help-policy CMP0066" for policy
actual-err> details. Use the cmake_policy command to set the policy and suppress this
actual-err> warning.
actual-err>
actual-err> For compatibility with older versions of CMake, try_compile is not honoring
actual-err> caller config-specific compiler flags (e.g. CMAKE_C_FLAGS_DEBUG) in the
actual-err> test project.
actual-err> Call Stack (most recent call first):
actual-err> CMakeLists.txt:3 (include)
actual-err> This warning is for project developers. Use -Wno-dev to suppress it.
actual-err>
actual-err> CMake Error at CMP0066.cmake:55 (message):
actual-err> try_compile with CMP0066 NEW did not fail with PP_ERROR:
actual-err>
actual-err> Change Dir: C:/cmake/Tests/RunCMake/try_compile/CMP0066-build/CMakeFiles/CMakeTmp
actual-err>
actual-err> Run Build Command:"C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe" "cmTC_3a3cf.vcxproj" "/p:Configuration=Release" "/p:VisualStudioVersion=11.0"
actual-err> Microsoft (R) Build Engine version 4.6.1590.0
actual-err> [Microsoft .NET Framework, version 4.0.30319.42000]
actual-err> Copyright (C) Microsoft Corporation. All rights reserved.
actual-err>
actual-err> Build started 1/10/2017 11:18:01 AM.
actual-err> Project "C:\cmake\Tests\RunCMake\try_compile\CMP0066-build\CMakeFiles\CMakeTmp\cmTC_3a3cf.vcxproj" on node 1 (default targets).
actual-err> PrepareForBuild:
actual-err> Creating directory "cmTC_3a3cf.dir\Release\".
actual-err> Creating directory "C:\cmake\Tests\RunCMake\try_compile\CMP0066-build\CMakeFiles\CMakeTmp\Release\".
actual-err> InitializeBuildStatus:
actual-err> Creating "cmTC_3a3cf.dir\Release\cmTC_3a3cf.unsuccessfulbuild" because "AlwaysCreate" was specified.
actual-err> ClCompile:
actual-err> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D PP_ERROR /D "CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTC_3a3cf.dir\Release\\" /Fd"cmTC_3a3cf.dir\Release\vc110.pdb" /Gd /TC /analyze- /errorReport:queue E:\cmake_orig\Tests\RunCMake\try_compile\src.c
actual-err> Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x86
actual-err> Copyright (C) Microsoft Corporation. All rights reserved.
actual-err>
actual-err> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D PP_ERROR /D "CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTC_3a3cf.dir\Release\\" /Fd"cmTC_3a3cf.dir\Release\vc110.pdb" /Gd /TC /analyze- /errorReport:queue E:\cmake_orig\Tests\RunCMake\try_compile\src.c
actual-err>
actual-err> src.c
actual-err> E:\cmake_orig\Tests\RunCMake\try_compile\src.c(6): fatal error C1004: unexpected end-of-file found [C:\cmake\Tests\RunCMake\try_compile\CMP0066-build\CMakeFiles\CMakeTmp\cmTC_3a3cf.vcxproj]
actual-err> Done Building Project "C:\cmake\Tests\RunCMake\try_compile\CMP0066-build\CMakeFiles\CMakeTmp\cmTC_3a3cf.vcxproj" (default targets) -- FAILED.
actual-err>
actual-err> Build FAILED.
actual-err>
actual-err> "C:\cmake\Tests\RunCMake\try_compile\CMP0066-build\CMakeFiles\CMakeTmp\cmTC_3a3cf.vcxproj" (default target) (1) ->
actual-err> (ClCompile target) ->
actual-err> E:\cmake_orig\Tests\RunCMake\try_compile\src.c(6): fatal error C1004: unexpected end-of-file found [C:\cmake\Tests\RunCMake\try_compile\CMP0066-build\CMakeFiles\CMakeTmp\cmTC_3a3cf.vcxproj]
actual-err>
actual-err> 0 Warning(s)
actual-err> 1 Error(s)
actual-err>
actual-err> Time Elapsed 00:00:00.13
actual-err>
actual-err> Call Stack (most recent call first):
actual-err> CMakeLists.txt:3 (include)
Call Stack (most recent call first):
E:/cmake_orig/Tests/RunCMake/try_compile/RunCMakeTest.cmake:49 (run_cmake)
-- CMP0067 - PASSED
```https://gitlab.kitware.com/cmake/cmake/-/issues/16549Can't find Windows Store SDK with Visual Studio 2017 RC2017-05-04T16:23:51-04:00Minmin GongCan't find Windows Store SDK with Visual Studio 2017 RCTrying to create VS2017 project from CMake, with -DCMAKE_SYSTEM_VERSION=10.0 and -DCMAKE_SYSTEM_NAME=WindowsStore but fails. The error is,
> A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windo...Trying to create VS2017 project from CMake, with -DCMAKE_SYSTEM_VERSION=10.0 and -DCMAKE_SYSTEM_NAME=WindowsStore but fails. The error is,
> A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windows Store '10.0' SDK. Please make sure that you have both installed.
I do have both SDKs installed, version 10.0.10493.0. And same parameters work on VS2015.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16548Suggestion: OpenSearch XML on documentation website2017-10-24T08:54:14-04:00Harry MallonSuggestion: OpenSearch XML on documentation websiteFirefox (and I assume other browsers) allow websites to advertise site specific search to be added to the search bar. This involves adding an OpenSearch XML to the website (http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSear...Firefox (and I assume other browsers) allow websites to advertise site specific search to be added to the search bar. This involves adding an OpenSearch XML to the website (http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document).
I think it would be a useful feature if the online documentation had this option. Obviously I can use site:cmake.org at the moment so not high priority at all.
EDITED: for spellinghttps://gitlab.kitware.com/cmake/cmake/-/issues/165473.5.1 on Ubuntu 16.04.1 i686 refuses to link -ldl when using static OpenSSL2017-05-04T16:23:51-04:00Ghost User3.5.1 on Ubuntu 16.04.1 i686 refuses to link -ldl when using static OpenSSLSteps to reproduce:
```
$ git clone --recursive https://github.com/monero-project/kovri
$ cd kovri/ && git checkout a7f4b24 # current HEAD on master
$ make static
```
Successful example:
[Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-...Steps to reproduce:
```
$ git clone --recursive https://github.com/monero-project/kovri
$ cd kovri/ && git checkout a7f4b24 # current HEAD on master
$ make static
```
Successful example:
[Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-generic x86_64)
cmake version 3.5.1
GNU 5.4.0](/uploads/1d0510d3a7461d9676b8f2f2a643dca5/64.log.txt)
```
[100%] Linking CXX executable ../../kovri
cd /home/anonimal/kovri/build/src/app && /usr/bin/cmake -E cmake_link_script CMakeFiles/kovri-app.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++1y -Wall -Wextra -Winvalid-pch -maes -pthread -g -static-libgcc -static-libstdc++ CMakeFiles/kovri-app.dir/main.cc.o CMakeFiles/kovri-app.dir/config.cc.o CMakeFiles/kovri-app.dir/daemon.cc.o CMakeFiles/kovri-app.dir/instance.cc.o CMakeFiles/kovri-app.dir/daemon_linux.cc.o -o ../../kovri -rdynamic ../../libkovri-client.a ../../libkovri-core.a -Wl,-Bstatic -lboost_chrono -lboost_log -lboost_program_options -lboost_date_time -lboost_thread -lboost_system -lboost_filesystem -lboost_regex -lboost_log_setup -lboost_atomic -Wl,-Bdynamic -lpthread -pthread ../../../deps/cpp-netlib/build/libs/network/src/libcppnetlib-client-connections.a -lpthread -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -ldl ../../../deps/cpp-netlib/build/libs/network/src/libcppnetlib-server-parsers.a ../../../deps/cpp-netlib/build/libs/network/src/libcppnetlib-uri.a -Wl,-Bstatic -lboost_chrono -lboost_date_time -lboost_thread -lboost_system -lboost_atomic -Wl,-Bdynamic -lpthread ../../../deps/cryptopp/build/libcryptopp.a
```
Problem example:
[Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-generic i686)
cmake version 3.5.1
GNU 5.4.0](/uploads/355f6cd883b1cc382fee114660c47c0f/32.log.txt)
```
[100%] Linking CXX executable ../../kovri
cd /home/anonimal/kovri/build/src/app && /usr/bin/cmake -E cmake_link_script CMakeFiles/kovri-app.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++1y -Wall -Wextra -Winvalid-pch -maes -pthread -g -static-libgcc -static-libstdc++ CMakeFiles/kovri-app.dir/main.cc.o CMakeFiles/kovri-app.dir/config.cc.o CMakeFiles/kovri-app.dir/daemon.cc.o CMakeFiles/kovri-app.di
r/instance.cc.o CMakeFiles/kovri-app.dir/daemon_linux.cc.o -o ../../kovri -rdynamic ../../libkovri-client.a ../../libkovri-core.a -Wl,-Bstatic -lboost_chrono -lboost_log -lboost_program_options -lboost_date_time -lboost_thread -lboost_sys
tem -lboost_filesystem -lboost_regex -lboost_log_setup -lboost_atomic -Wl,-Bdynamic -lpthread -pthread /home/anonimal/cpp-netlib/build/libs/network/src/libcppnetlib-client-connections.a -lboost_system -lboost_thread -lboost_chrono -lboost_
date_time -lboost_atomic -lpthread -Wl,-Bstatic -lssl -lcrypto /home/anonimal/cpp-netlib/build/libs/network/src/libcppnetlib-server-parsers.a /home/anonimal/cpp-netlib/build/libs/network/src/libcppnetlib-uri.a -Wl,-Bdynamic -lpthread ../..
/../deps/cryptopp/build/libcryptopp.a
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x46f): undefined reference to `dlopen'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x486): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x49b): undefined reference to `dladdr'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x4ab): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x4fa): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0xa): undefined reference to `dlopen'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x20): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x2a): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
(.text+0x32d): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
(.text+0x3ad): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
(.text+0x42d): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
(.text+0x4ad): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x518): undefined reference to `dlopen'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x575): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x5ae): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
(.text+0x641): undefined reference to `dladdr'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
(.text+0x6a1): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
(.text+0x70b): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
src/app/CMakeFiles/kovri-app.dir/build.make:226: recipe for target 'kovri' failed
make[3]: *** [kovri] Error 1
make[3]: Leaving directory '/home/anonimal/kovri/build'
CMakeFiles/Makefile2:113: recipe for target 'src/app/CMakeFiles/kovri-app.dir/all' failed
make[2]: *** [src/app/CMakeFiles/kovri-app.dir/all] Error 2
make[2]: Leaving directory '/home/anonimal/kovri/build'
Makefile:130: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/anonimal/kovri/build'
Makefile:114: recipe for target 'static' failed
make: *** [static] Error 2
```
Notes:
- This issue is not reproducible on [any other of our supported platforms](https://build.getmonero.org/waterfall) (only i686)
- The area which targets `dl` can also be seen [here](https://github.com/anonimal/cpp-netlib/commit/80b46bd62dab4114636ad4f316b5fb404c72aef0) for easy reference (the complete recipes are available in the submodule)
Perhaps the issue is incorrect implementation on my part?https://gitlab.kitware.com/cmake/cmake/-/issues/16546VS: Cannot compile two `.asm` files with the same name2017-10-13T13:17:55-04:00Egor PuginVS: Cannot compile two `.asm` files with the same nameHi,
There's some mess with generated Object File property in VS solution for .asm files. The repro is in archive.
Unpack, then run:
```
mkdir win32 && cd win32 && cmake .. && cmake --build .
```
I see:
```
CustomBuild:
B...Hi,
There's some mess with generated Object File property in VS solution for .asm files. The repro is in archive.
Unpack, then run:
```
mkdir win32 && cd win32 && cmake .. && cmake --build .
```
I see:
```
CustomBuild:
Building Custom Rule H:/Temp/101/CMakeLists.txt
CMake does not need to re-run because H:\Temp\101\win32\CMakeFiles\generate.stamp is up-to-date.
_MASM:
Assembling H:\Temp\101\1.asm...
cmd.exe /C "C:\Users\egor\AppData\Local\Temp\tmp5dd0185685ca4204854801f7d64c5345.cmd"
ml.exe /c /nologo /Zi /Fo"x.dir\Debug\/1.obj" /D"_M_X86" /D"CMAKE_INTDIR="Debug"" /W3 /errorReport:prompt /safeseh /TaH:\Temp\101\1.asm
_MASM:
Assembling H:\Temp\101\b3e3654a.dir\1.asm...
cmd.exe /C "C:\Users\egor\AppData\Local\Temp\tmp9593c5d4a3f34d2baea0f10f674db120.cmd"
ml.exe /c /nologo /Zi /Fo"x.dir\Debug\/b3e3654a.dir/1.obj" /D"_M_X86" /D"CMAKE_INTDIR="Debug"" /W3 /errorReport:prompt /safeseh /TaH:\Temp\101\b3
e3654a.dir\1.asm
H:\Temp\101\b3e3654a.dir\1.asm(1): fatal error A1000: cannot open file : x.dir\Debug\/b3e365a. [H:\Temp\101\win32\x.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\masm.targets(50,5): error MSB3721: The command "ml.exe /c /nologo /Zi /Fo"
x.dir\Debug\/b3e3654a.dir/1.obj" /D"_M_X86" /D"CMAKE_INTDIR="Debug"" /W3 /errorReport:prompt /safeseh /TaH:\Temp\101\b3e3654a.dir\1.asm" exited wit
h code 1. [H:\Temp\101\win32\x.vcxproj]
Done Building Project "H:\Temp\101\win32\x.vcxproj" (default targets) -- FAILED.
```
`/Fo` option for the second file (under tricky dir) is completely broken! `/Fo"x.dir\Debug\/b3e3654a.dir/1.obj"`
```
H:\Temp\101\b3e3654a.dir\1.asm(1): fatal error A1000: cannot open file : x.dir\Debug\/b3e365a.
```
[asm_repro.zip](/uploads/5ea1b29b6e4912426e3370b1e4470dab/asm_repro.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/16545Please merge curl upstream2017-05-04T16:23:51-04:00Paweł StankowskiPlease merge curl upstreamI found a bug in curl's CMake files when trying to compile it with Open Watcom. The fix was already accepted in curl project: https://github.com/curl/curl/pull/1195
Could you please merge these changes into CMake repo?I found a bug in curl's CMake files when trying to compile it with Open Watcom. The fix was already accepted in curl project: https://github.com/curl/curl/pull/1195
Could you please merge these changes into CMake repo?https://gitlab.kitware.com/cmake/cmake/-/issues/16544[ExternalProject] Using "DOWNLOAD_NO_EXTRACT 1" together with "LOG_DOWNLOAD 1...2017-07-09T20:25:30-04:00Janosch Hildebrand[ExternalProject] Using "DOWNLOAD_NO_EXTRACT 1" together with "LOG_DOWNLOAD 1" results in errorIn ExternalProject_Add, setting both `DOWNLOAD_NO_EXTRACT` and `LOG_DOWNLOAD` (to 1) results in an error when `execute_process` tries to execute the empty extract command.
The following code should reproduce the issue (tested with 3.7.1...In ExternalProject_Add, setting both `DOWNLOAD_NO_EXTRACT` and `LOG_DOWNLOAD` (to 1) results in an error when `execute_process` tries to execute the empty extract command.
The following code should reproduce the issue (tested with 3.7.1).
A CMakeLists.txt file is attached.
```cmake
include("ExternalProject")
ExternalProject_Add(
error_example
URL https://gitlab.kitware.com/cmake/cmake/repository/archive.tar.gz?ref=master
DOWNLOAD_NO_EXTRACT 1
BUILD_COMMAND ""
INSTALL_COMMAND ""
LOG_DOWNLOAD 1
)
```
Resulting error message (in the created log file):
> CMake Error at error_example-stamp/error_example-download--impl.cmake:23 (execute_process):
> execute_process given COMMAND argument with no value.[CMakeLists.txt](/uploads/3c4abe42a10409cdaf8efb369e6bffa9/CMakeLists.txt)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/16543LINK_OPTIONS and INTERFACE_LINK_OPTIONS properties2018-08-09T10:36:48-04:00Vladimír VondrušLINK_OPTIONS and INTERFACE_LINK_OPTIONS propertiesFor the compiler there are per-target `COMPILE_OPTIONS`, `INTERFACE_COMPILE_OPTIONS` and (deprecated) `COMPILE_FLAGS`. `COMPILE_OPTIONS` can be also used per-directory. All of them support generator expressions and they are really powerf...For the compiler there are per-target `COMPILE_OPTIONS`, `INTERFACE_COMPILE_OPTIONS` and (deprecated) `COMPILE_FLAGS`. `COMPILE_OPTIONS` can be also used per-directory. All of them support generator expressions and they are really powerful and great to use.
For the linker there's just per-target `LINK_FLAGS` behaving like the deprecated `COMPILE_FLAGS` and nothing else.
I have two use cases:
- A `Find` module that creates an imported target for some static library. The library needs some interface compiler options, which I'm happily adding through `INTERFACE_COMPILE_OPTIONS`, but it also needs some interface linker options and for those currently have to modify the global `CMAKE_*_LINKER_FLAGS`, which is really ugly and completely against the modern CMake workflow.
- A set of pedantic options passed to compiler/linker in order to harden the builds, which gets enabled only if the user sets a particular property on a target/directory. Currently I'm achieving this through per-directory `COMPILE_OPTIONS` and `COMPILE_DEFINITIONS` properties that get inherited by the targets and uses a generator expression for the conditional enablement, as shown below. Unfortunately there is no per-directory `LINK_OPTIONS` property that would behave the same way as `COMPILE_OPTIONS` so I can't do similar thing for the linker.
```cmake
set_property(DIRECTORY APPEND PROPERTY COMPILE_OPTIONS "$<$<BOOL:$<TARGET_PROPERTY:USE_PEDANTIC_FLAGS>>:-Wall;-Werror;-Wpedantic; ...>")
set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS "$<$<BOOL:$<TARGET_PROPERTY:USE_PEDANTIC_FLAGS>>:...>")
add_executable(myapp app.cpp)
set_target_properties(myapp PRIVATE USE_PEDANTIC_FLAGS ON) # Enables the pedantic flags and defines
```
Would it be possible to add per-target and per-directory `LINK_OPTIONS` property and per-target `INTERFACE_LINK_OPTIONS` property? I tried to find anything about this subject and found just [this old e-mail thread](http://public.kitware.com/pipermail/cmake/2016-May/063357.html), is there any reason that prevents those properties to exist?
EDIT: Oh, and one more: `target_link_options()` to make the feature set equivalent to compile options.https://gitlab.kitware.com/cmake/cmake/-/issues/16542CMAKE_INSTALL_UCRT_LIBRARIES should be aware of CMAKE_INSTALL_DEBUG_LIBRARIES...2017-05-04T16:23:51-04:00Bjoern ThielCMAKE_INSTALL_UCRT_LIBRARIES should be aware of CMAKE_INSTALL_DEBUG_LIBRARIES_ONLY and CMAKE_INSTALL_DEBUG_LIBRARIESTo achieve this I suggest to make the following change to InstallRequiredSystemLibraries.cmake:
```cmake
if(CMAKE_INSTALL_UCRT_LIBRARIES AND NOT v VERSION_LESS 14)
# Find the Windows Kits directory.
get_filename_compo...To achieve this I suggest to make the following change to InstallRequiredSystemLibraries.cmake:
```cmake
if(CMAKE_INSTALL_UCRT_LIBRARIES AND NOT v VERSION_LESS 14)
# Find the Windows Kits directory.
get_filename_component(windows_kits_dir
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots;KitsRoot10]" ABSOLUTE)
set(programfilesx86 "ProgramFiles(x86)")
find_path(WINDOWS_KITS_DIR NAMES Redist/ucrt/DLLs/${CMAKE_MSVC_ARCH}/ucrtbase.dll
PATHS
"${windows_kits_dir}"
"$ENV{ProgramFiles}/Windows Kits/10"
"$ENV{${programfilesx86}}/Windows Kits/10"
)
mark_as_advanced(WINDOWS_KITS_DIR)
# Glob the list of UCRT DLLs.
if(NOT CMAKE_INSTALL_DEBUG_LIBRARIES_ONLY)
file(GLOB __ucrt_dlls "${WINDOWS_KITS_DIR}/Redist/ucrt/DLLs/${CMAKE_MSVC_ARCH}/*.dll")
list(APPEND __install__libs ${__ucrt_dlls})
endif()
if(CMAKE_INSTALL_DEBUG_LIBRARIES)
file(GLOB __ucrt_dlls "${WINDOWS_KITS_DIR}/bin/${CMAKE_MSVC_ARCH}/ucrt/*.dll")
list(APPEND __install__libs ${__ucrt_dlls})
endif()
endif()
```https://gitlab.kitware.com/cmake/cmake/-/issues/16541Variable expansion in target_include_directories fails (depending on position)2017-05-04T16:23:51-04:00Nat!Variable expansion in target_include_directories fails (depending on position)The variable expansion ${TARGET_PLATFORM_INCLUDE_DIRECTORIES}" works or
fails depending on its positiion relative to other statements inside of
target_include_directories:
CMake Error at CMakeLists.txt:12 (target_include_directories):
...The variable expansion ${TARGET_PLATFORM_INCLUDE_DIRECTORIES}" works or
fails depending on its positiion relative to other statements inside of
target_include_directories:
CMake Error at CMakeLists.txt:12 (target_include_directories):
target_include_directories called with invalid arguments
CMakeLists.txt:
```
cmake_minimum_required (VERSION 3.0)
project (Foo)
add_library( Foo SHARED
foo.c
)
set( TARGET_PLATFORM_INCLUDE_DIRECTORIES "PUBLIC macosx")
message( STATUS "TARGET_PLATFORM_INCLUDE_DIRECTORIES is
${TARGET_PLATFORM_INCLUDE_DIRECTORIES}")
target_include_directories( Foo BEFORE
${TARGET_PLATFORM_INCLUDE_DIRECTORIES}
PRIVATE private
# ${TARGET_PLATFORM_INCLUDE_DIRECTORIES}
)
```
Using cmake version 3.7.1 on MacOSX 10.10.
Ciao
Nat!
P.S. Subscribed to mailing list, but posting generated a bounce.https://gitlab.kitware.com/cmake/cmake/-/issues/16540cmake-3.7.1 looks for libpthreads on ubuntu-14.042021-04-08T07:48:26-04:00Billcmake-3.7.1 looks for libpthreads on ubuntu-14.04I tried cmake 3.3.0, 3.3.2, and 3.7.1 to get an application to build on our ubuntu-14.04 box. In each case the build would die looking for -lpthreads instead of -lpthread. The cmake files seemed to be asking correctly and in tracking i...I tried cmake 3.3.0, 3.3.2, and 3.7.1 to get an application to build on our ubuntu-14.04 box. In each case the build would die looking for -lpthreads instead of -lpthread. The cmake files seemed to be asking correctly and in tracking it down I noticed cmake has the same problem when it builds itself:
```
root@crick:/share/apps/src/cmake-3.7.1# cat ./CMakeFiles/CMakeError.log | grep -i pthreads
Determining if the function pthread_create exists in the pthreads failed with the following output:
/usr/bin/gcc -w -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTC_bd21b.dir/CheckFunctionExists.c.o -o cmTC_bd21b -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
root@crick:/share/apps/src/cmake-3.7.1#
```
The libraries that cmake should find:
```
root@crick:/share/apps/src/cmake-3.7.1# locate libpthread
/lib/x86_64-linux-gnu/libpthread-2.19.so
/lib/x86_64-linux-gnu/libpthread.so.0
/usr/lib/x86_64-linux-gnu/libpthread.a
/usr/lib/x86_64-linux-gnu/libpthread.so
```
```
root@crick:/share/apps/src/cmake-3.7.1# uname -a; lsb_release -a
Linux crick 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
```
At least on ubuntu-14.04 cmake should look for libpthread not libpthreads.https://gitlab.kitware.com/cmake/cmake/-/issues/16539Server Mode: CMake process crashes when running into INTERFACE_LIBRARY targets2017-05-04T16:23:51-04:00Janick Martinez EsturoServer Mode: CMake process crashes when running into INTERFACE_LIBRARY targetsIn a complex project the cmake server crashes with
```
cmake: /home/janickm/.local/pkg/cmake/Source/cmGeneratorTarget.cxx:954: void cmGeneratorTarget::GetSourceFiles(std::vector<std::__cxx11::basic_string<char> >&, const string&) con...In a complex project the cmake server crashes with
```
cmake: /home/janickm/.local/pkg/cmake/Source/cmGeneratorTarget.cxx:954: void cmGeneratorTarget::GetSourceFiles(std::vector<std::__cxx11::basic_string<char> >&, const string&) const: Assertion `this->GetType() != cmState::INTERFACE_LIBRARY' failed.
```
using
```
$ cmake --version
cmake version 3.7.1
```
for the `codemodel` message type.
The project makes heavy use of interface libraries, but works fine in non-server mode.
---
The following commands are used
```
$ cmake -E server --experimental --debug
```
```
[== "CMake Server" ==[
{
"buildDirectory": "/home/../<cmake-project>/build",
"cookie": "",
"generator": "Ninja",
"major": 1,
"protocolVersion": {
"major": 1
},
"sourceDirectory": "/home/../<cmake-project>",
"type": "handshake"
}
]== "CMake Server" ==]
```
```
[== "CMake Server" ==[
{
"cacheArguments": [],
"type": "configure"
}
]== "CMake Server" ==]
```
```
[== "CMake Server" ==[
{"type":"compute"}
]== "CMake Server" ==]
```
```
[== "CMake Server" ==[
{"type":"codemodel"}
]== "CMake Server" ==]
```
---
This was originally reported at https://bugreports.qt.io/browse/QTCREATORBUG-174963.7.2Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16538Setting CMAKE_EXECUTABLE_SUFFIX and TARGET_SUPPORTS_SHARED_LIBS from toolchai...2021-10-15T10:16:12-04:00KUGA2Setting CMAKE_EXECUTABLE_SUFFIX and TARGET_SUPPORTS_SHARED_LIBS from toolchain file is not possibleHi,
i am writing a toolchainfile for an embedded operating system. This OS has file extensions for its executables and does not support shared libraries. As i see this, this is something that should be noted in the toolchain file.
Its ...Hi,
i am writing a toolchainfile for an embedded operating system. This OS has file extensions for its executables and does not support shared libraries. As i see this, this is something that should be noted in the toolchain file.
Its not possible.
I have to apply these settings after the project() call, which is inside the top level CMakeLists.txt. Since this project is also compiled for Linux, we have to do some nasty workaround in the projects CMakeLists.txt to fix this.
You can reproduce this issue without a toolchain file:
`
SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS "TRUE")
GET_PROPERTY(test GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS)
set(CMAKE_EXECUTABLE_SUFFIX .ext)
MESSAGE("TOPDIR1: -" ${test} "- -" ${CMAKE_EXECUTABLE_SUFFIX} "-")
project(mytestproject)
GET_PROPERTY(test GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS)`https://gitlab.kitware.com/cmake/cmake/-/issues/16537Ninja generator adds "/DEF" linker flag for static libraries2017-05-04T16:23:51-04:00John SmithNinja generator adds "/DEF" linker flag for static librariesSome of my Windows code statically links against [FreeRDP](https://github.com/FreeRDP/FreeRDP). Previously I was using the "NMake Makefiles JOM" generator with [jom](https://wiki.qt.io/Jom) to build my code. The code built fine. In th...Some of my Windows code statically links against [FreeRDP](https://github.com/FreeRDP/FreeRDP). Previously I was using the "NMake Makefiles JOM" generator with [jom](https://wiki.qt.io/Jom) to build my code. The code built fine. In the past, I also used regular nmake without problems.
Recently I switched to using the "Ninja" generator with [ninja](https://ninja-build.org/). The code still compiled fine, but I ran into problems running my executable. Every time I ran the executable, Windows would complain that "freerdp-client.dll" was missing. That was odd because I explicitly told FreeRDP to be built as a static library by putting this in my CMakeLists.txt:
```
set(BUILD_SHARED_LIBS OFF)
```
I eventually tracked the problem down to this code from [client/common/CMakeLists.txt around line 42](https://github.com/FreeRDP/FreeRDP/blob/6fa36081112c46951096cddfacc0f760e4728b25/client/common/CMakeLists.txt#L42):
```
if(MSVC)
set(${MODULE_PREFIX}_SRCS ${${MODULE_PREFIX}_SRCS} module.def)
endif()
```
That line of code was causing the Ninja generator to add this linker flag to `LINK_FLAGS`:
```
/DEF:C:\path\to\FreeRDP\client\common\module.def
```
I think the `/DEF` linker flag was causing the linker to link freerdp-client.lib dynamically instead of statically to my code. The NMake and JOM generators did not add `/DEF`to `LINK_FLAGS` even though I was using the same `CMakeLists.txt`. This difference in behavior was introduced recently in 43ce4414c479af6b04e93decaf7f69938c92a323, which added this code to `cmNinjaNormalTargetGenerator::WriteDeviceLinkStatement` around line [660](https://gitlab.kitware.com/robertmaynard/cmake/commit/43ce4414c479af6b04e93decaf7f69938c92a323#e41573099084ba2bf39bf06a506af881f053382c_421_660):
```
this->AddModuleDefinitionFlag(linkLineComputer.get(), vars["LINK_FLAGS"]);
```
Inside `AddModuleDefinitionFlag`, the `/DEF` linker flag is added if a module definition file is in the list of sources. I don't see the Nmake or JOM generators calling `AddModuleDefinitionFlag` at all. Given that my code compiles and links correctly with JOM and NMake, I suspect this is a bug in the Ninja generator but I am not sure.
I confirmed that removing `module.def` from the list of sources removes `/DEF` from `LINK_FLAGS` when using the Ninja generator and that my executable now runs correctly without looking for `freerdp-client.dll`.
Coincidentally, the FreeRDP project recently modified their CMakeLists.txt files in [PR 3168](https://github.com/FreeRDP/FreeRDP/pull/3168) to [completely remove module.def from the list of sources](https://github.com/FreeRDP/FreeRDP/pull/3168/commits/c182be093dd909da953e87b3cdeb188e71e7bb73). Thus, this problem should fix itself when I eventually upgrade to the latest version of FreeRDP but it still doesn't explain the difference between the Nmake/JOM and Ninja generators.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16536Cross-compiling with CMake for Android x86 with API lower than 21 fails2017-06-09T14:43:56-04:00ViktorCross-compiling with CMake for Android x86 with API lower than 21 failsWhen using CMake options as described on official site:
`cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_SYSTEM_VERSION=9 -DCMAKE_ANDROID_ARCH_ABI=x86 -DCMAKE_ANDROID_NDK=/path/to/android-ndk -DCMAKE_ANDROID_STL_TYPE=c++_static`
...When using CMake options as described on official site:
`cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_SYSTEM_VERSION=9 -DCMAKE_ANDROID_ARCH_ABI=x86 -DCMAKE_ANDROID_NDK=/path/to/android-ndk -DCMAKE_ANDROID_STL_TYPE=c++_static`
`https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-android`
and building for Android x86 with API version < 21 and gcc 4.9 on host x64 Ubuntu machine, then we get the following error:
```
/.../boost/1.61.0/build/include/boost/asio/impl/serial_port_base.ipp: In member function 'boost::system::error_code boost::asio::serial_port_base::baud_rate::store(termios&, boost::system::error_code&) const':
/.../boost/1.61.0/build/include/boost/asio/impl/serial_port_base.ipp:119:3: error: '::cfsetspeed' has not been declared
::cfsetspeed(&storage, baud);
^
make: *** [all] Error 2
```
Probably this error occured because `_BSD_SOURCE` is defined in following header:
`path_to_ndk/toolchains/x86-4.9/prebuilt/linux-x86_64/lib/gcc/i686-linux-android/4.9/include-fixed/asm/posix_types.h` included instead of needed
`path_to_ndk/platforms/android-9/arch-x86/usr/include/asm/posix_types.h` , that's why `_BSD_SOURCE` is defined and it leads to errors when compiling third-party libraries (Boost etc)
When using custom toolchain file `https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain.cmake` `_BSD_SOURCE` gets never defined.
3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16535CMAKE_ASM_COMPILER_TARGET not set on Android after enable_language(ASM) with ...2017-05-04T16:23:52-04:00Florent CastelliCMAKE_ASM_COMPILER_TARGET not set on Android after enable_language(ASM) with ClangCompiling some ASM files, I get the following command line generated:
`/home/travis/build/Orphis/boost-cmake/android-ndk-r12b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --sysroot=/home/travis/build/Orphis/boost-cmake/android-ndk-r...Compiling some ASM files, I get the following command line generated:
`/home/travis/build/Orphis/boost-cmake/android-ndk-r12b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --sysroot=/home/travis/build/Orphis/boost-cmake/android-ndk-r12b/platforms/android-24/arch-arm64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_EXPORT -DBOOST_CONTEXT_SOURCE=1 -isystem ../boost/boost_1_63_0 -g -fPIC -w -MD -MT CMakeFiles/Boost_context.dir/libs/context/jump_combined.S.o -MF CMakeFiles/Boost_context.dir/libs/context/jump_combined.S.o.d -o CMakeFiles/Boost_context.dir/libs/context/jump_combined.S.o -c /home/travis/build/Orphis/boost-cmake/libs/context/jump_combined.S`
This will build the file for the HOST architecture as it is missing a flag like "--target=armv7-none-linux-androideabi" flag (for compiling for ARMv7 for example).
When I manually set it (for example to CMAKE_CXX_COMPILER_TARGET), I get the file properly compiled for the intended architecture.
I'll try to investigate a fix, but I'm sure you can come up with a fix pretty quickly :)https://gitlab.kitware.com/cmake/cmake/-/issues/16534FindHDF5 causes DLLs to appear on the link line on Windows2017-05-04T16:23:52-04:00Ben BoeckelFindHDF5 causes DLLs to appear on the link line on WindowsThe following line in the `FindHDF5` module causes the `.dll` file to be found rather than the `.lib` file:
```cmake
get_target_property(_lang_location ${HDF5_${_lang}_TARGET}${_suffix} LOCATION)
```
because the `IMPORTED_LOCATION_<CON...The following line in the `FindHDF5` module causes the `.dll` file to be found rather than the `.lib` file:
```cmake
get_target_property(_lang_location ${HDF5_${_lang}_TARGET}${_suffix} LOCATION)
```
because the `IMPORTED_LOCATION_<CONFIG>` property is the `.dll` while `IMPORTED_IMPLIB_<CONFIG>` is the `.lib` file.
Cc: @chuck.atkinshttps://gitlab.kitware.com/cmake/cmake/-/issues/16533Xcode Generator: Custom Project Name2023-09-18T06:23:18-04:00AlexDenisovXcode Generator: Custom Project NameHi there.
I'd like to bring a small feature: custom name for a Xcode project.
Here is my motivation: on my machine I have few copies of LLVM, for each of them I have separate Xcode project.
The problem appears when I switch between di...Hi there.
I'd like to bring a small feature: custom name for a Xcode project.
Here is my motivation: on my machine I have few copies of LLVM, for each of them I have separate Xcode project.
The problem appears when I switch between different Xcode projects, or when I want to open another project: there is almost no way to determine which copy I'm working with. The only way to differentiate things now is to remember the target I worked with in each project.
But it's so annoying, error-prone, and counter-productive so I'd like CMake to generate me a project with a different, custom name.
i.e.:
```
cmake -G Xcode ~/Projects/LLVM/src
cmake -G Xcode -DCMAKE_XCODE_PROJECT_NAME=Mull ~/Projects/Mull/src
cmake -G Xcode -DCMAKE_XCODE_PROJECT_NAME=IRTests ~/Projects/Mull/Lab/src
```
where the commands will spit out xcode projects as the following: `LLVM.xcodeproj`, `Mull.xcodeproj`, `IRTests.xcodeproj`.
So far I looked into `cmGlobalXCodeGenerator` and found that this change can be done easily (see the patch below).
Now I have several questions:
1. Can such a feature be accepted into upstream?
2. What is the recommended way to write tests for this feature?
3. What else needs to be done to make this work besides the change below?
I will also appreciate any reference to more detailed contributing guidelines, if there are any.
P.S. the patch:
```diff
diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx
index 736aa91..4fea196 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3264,9 +3264,16 @@ void cmGlobalXCodeGenerator::OutputXCodeProject(
if (!this->CreateXCodeObjects(root, generators)) {
return;
}
+
+ const char *customProjectName = this->CurrentMakefile->GetDefinition("CMAKE_XCODE_PROJECT_NAME");
+ std::string projectName = root->GetProjectName();
+ if (customProjectName) {
+ projectName = std::string(customProjectName);
+ }
+
std::string xcodeDir = root->GetCurrentBinaryDirectory();
xcodeDir += "/";
- xcodeDir += root->GetProjectName();
+ xcodeDir += projectName;
xcodeDir += ".xcode";
if (this->XcodeVersion > 20) {
xcodeDir += "proj";
```Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16532need to specialize INTERFACE_POSITION_INDEPENDENT_CODE for executables2018-11-12T15:43:20-05:00Eduard Valeyevneed to specialize INTERFACE_POSITION_INDEPENDENT_CODE for executablesthe purpose of INTERFACE_POSITION_INDEPENDENT_CODE is to force consumers to set POSITION_INDEPENDENT_CODE . What is desired is to specify this for executable targets only. A new property is needed (INTERFACE_POSITION_INDEPENDENT_EXECUTAB...the purpose of INTERFACE_POSITION_INDEPENDENT_CODE is to force consumers to set POSITION_INDEPENDENT_CODE . What is desired is to specify this for executable targets only. A new property is needed (INTERFACE_POSITION_INDEPENDENT_EXECUTABLE ?).
Rationale: it is sometimes necessary to ensure that any executables created with library X are non-PIE due to the PIE mechanism interfering with the mechanics of X. Setting INTERFACE_POSITION_INDEPENDENT_CODE property for X not only forces the executables linking against X to set POSITION_INDEPENDENT_CODE but also the libraries linking against X to set POSITION_INDEPENDENT_CODE; these two are quite different things and only the former is necessary to ensure that X works correctly. This places an unnecessary burden on the user of X.