CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-10-13T13:17:55-04:00https://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/16451FindCURL does not search `C:\Program Files (x86)\CURL`2017-10-13T13:17:55-04:00EthanFindCURL does not search `C:\Program Files (x86)\CURL`I have tried to install a couple of libraries that depend on libcurl. So I downloaded curl 7.51 and build and ran INSTALL.vcxproj and it installed fine.
However, when I run a cmake file that uses `find_package` to get CURL, it fails c...I have tried to install a couple of libraries that depend on libcurl. So I downloaded curl 7.51 and build and ran INSTALL.vcxproj and it installed fine.
However, when I run a cmake file that uses `find_package` to get CURL, it fails complaining it cannot find curl. cURL is installed in C:\Program Files (x86)\CURL for me. shouldn't cmake be looking for CURL in this standard path?
Am I doing something wrong?https://gitlab.kitware.com/cmake/cmake/-/issues/16642Partial support of permissions on Windows (read-only attribute)2017-10-13T13:17:55-04:00ValentynPartial support of permissions on Windows (read-only attribute)The following works fine on Linux:
```
install (FILES "${SOME_PATH}"
DESTINATION "${SOME_DIRECTORY}"
PERMISSIONS OWNER_READ GROUP_READ WORLD_READ
COMPONENT SomeComponent)
```
It does not work on Windows. I can manually set read-onl...The following works fine on Linux:
```
install (FILES "${SOME_PATH}"
DESTINATION "${SOME_DIRECTORY}"
PERMISSIONS OWNER_READ GROUP_READ WORLD_READ
COMPONENT SomeComponent)
```
It does not work on Windows. I can manually set read-only attribute for a file or folder on Windows, so it would be nice if CMake partially supported Windows in this regard too.
We use this technique to prevent case when some header file is opened in IDE from installation directory, developer modifies it (thinking it is in the repo) and then these modifications are overwritten by the install.https://gitlab.kitware.com/cmake/cmake/-/issues/16721CPACK_RPM_DEBUGINFO_PACKAGE =on + CPACK_RPM_${COMPONENT}_DEBUGINFO_PACKAGE=OF...2017-10-13T13:17:55-04:00Daniel BlackCPACK_RPM_DEBUGINFO_PACKAGE =on + CPACK_RPM_${COMPONENT}_DEBUGINFO_PACKAGE=OFF still builds debuginfo for componentsmall feature request. Should be possible to disable a small number of components.small feature request. Should be possible to disable a small number of components.Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16315Promote -B and -H from internal to experimental options2017-10-13T13:17:55-04:00_ViPromote -B and -H from internal to experimental optionsThis pair makes it easier to avoid cluttering scripts or terminal sessions with `cd`.
Using them alone (only -H or only -B) is confusing may issue warning.
There may also be longer variants like `--source-directory=...` and `--buil...This pair makes it easier to avoid cluttering scripts or terminal sessions with `cd`.
Using them alone (only -H or only -B) is confusing may issue warning.
There may also be longer variants like `--source-directory=...` and `--build-directory=...`.
Related link: http://public.kitware.com/pipermail/cmake-developers/2016-June/028843.htmlhttps://gitlab.kitware.com/cmake/cmake/-/issues/16494CMake check for required CMake re-run regression in Visual Studio 2017 RC pro...2017-10-13T13:17:55-04:00David HunterCMake check for required CMake re-run regression in Visual Studio 2017 RC projects using 3.7.1When compiling using a Cmake generated Visual Studio 2017 RC project file there appears to be a lot more checks for whether CMake need to re-run or not.
Specifically if I compile project Foo the Visual Studio output window contains larg...When compiling using a Cmake generated Visual Studio 2017 RC project file there appears to be a lot more checks for whether CMake need to re-run or not.
Specifically if I compile project Foo the Visual Studio output window contains large numbers of lines such as
"CMake does not need to re-run because ... .../CMakeFiles/generate.statmp is up-to-date"
A line such as the above is produced for each project in the solution, regardless of whether project Foo depends on it or not.
Even worse the output is repeated for each project on which Foo is actually dependent.
So if you have a solution with 100 projects and you build a project that is dependent on all the other 99 you will see about 9,900 lines.
This represents a massive performance regression to Visual Studio 2015 which does not exhibit this behaviour at all. The
only times you see lines like "CMake does not need to re-run because" is when a CmakeLists.txt file is touched wich is what I
would expect.
I have diffed the vcxproj files and can't see anything that might account for this. I have also been experimenting with VS 2017
to see if it has different behaviour but have not found anything. I will continue to look for a root cause, hopefully this is already a "known" issue.https://gitlab.kitware.com/cmake/cmake/-/issues/16601Highlight warning and error bits in CDash submissions2017-10-13T13:17:55-04:00Ben BoeckelHighlight warning and error bits in CDash submissionsThe text uploaded for errors and warnings would be nice with the following markup around the bits that match the regex so that it is easier to see what the actual issues are:
```html
<span class="error-match">text matching error regex</...The text uploaded for errors and warnings would be nice with the following markup around the bits that match the regex so that it is easier to see what the actual issues are:
```html
<span class="error-match">text matching error regex</span>
```
```html
<span class="warning-match">text matching warning regex</span>
```
Requires CDash changes as well.
Cc: @brad.king @zackgalbreathhttps://gitlab.kitware.com/cmake/cmake/-/issues/16719Visual Studio generators create VC project files even if the solution only ha...2017-10-13T13:17:55-04:00Javier MartínVisual Studio generators create VC project files even if the solution only has enabled FortranWhen generating Visual Studio solutions and project files for a Fortran-only project, CMake correctly creates `.vfproj` project files for the binary targets, but any other targets (like custom targets or support targets like install) are...When generating Visual Studio solutions and project files for a Fortran-only project, CMake correctly creates `.vfproj` project files for the binary targets, but any other targets (like custom targets or support targets like install) are generated as `.vcproj` files for Visual C/C++. This makes those projects unusable if Visual C++ is not installed, and in some VS versions it can also cause a crash on build.
In particular, with Intel Fortran 12.0 installed with the Visual Studio 2008 "shell only" (that is, without VC++), the VS shell cannot load the "support projects" `ALL_BUILD`, `INSTALL` and `ZERO_CHECK`. Since _all_ projects depend on the latter, this appears to trigger some bug in VS2008 that crashes the VS shell. I guess that in other versions of VS, it will simply refuse to build because a project depends on another that is not (and cannot be) loaded.
The root cause is that the choice of the project type depends on `cmGlobalVisualStudioGenerator::TargetIsFortranOnly(cmGeneratorTarget const*)`, which returns true if and only if the target in question has a single language enabled and that language is Fortran. However, the "support" projects mentioned above have _no_ languages enabled at all, so CMake falls back to the default of creating a VC++ project.
I propose a patch with a simple solution: since Fortran projects can also carry custom actions, `TargetIsFortranOnly` should *also* return true if the target has no languages enabled _but_ the overall CMake project has enabled only Fortran (ignoring RC, the resource compiler). Thus, for a project which only has Fortran enabled, the "support" targets would be created as `.vfproj` files, while for a mixed C/Fortran project (or for a project without Fortran) the current `.vcproj` default would be kept.
[cmake-vfproj.patch](/uploads/36a8fdf523ef2038e842ed5e400219a1/cmake-vfproj.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/16600Visual Studio 2017 generator does not create solution folders2017-10-13T13:17:55-04:00Dejan ČrnilaVisual Studio 2017 generator does not create solution folderscommand set_target_properties(targetname PROPERTIES FOLDER targetfolder) seem to be ignored. All targets are on root folder
I tried it with "Visual Studio 15 2017 Win64" generator.command set_target_properties(targetname PROPERTIES FOLDER targetfolder) seem to be ignored. All targets are on root folder
I tried it with "Visual Studio 15 2017 Win64" generator.https://gitlab.kitware.com/cmake/cmake/-/issues/16314Make --rerun-failed generate a complete Test.xml2017-10-13T13:17:55-04:00Dirk ThomasMake --rerun-failed generate a complete Test.xmlCurrently when using `ctest --rerun-failed` the `Test.xml` file is being overwritten with only the test which failed before and have been rerun. This behavior doesn't allow reasonable results when integrating CTest in a CI system like Je...Currently when using `ctest --rerun-failed` the `Test.xml` file is being overwritten with only the test which failed before and have been rerun. This behavior doesn't allow reasonable results when integrating CTest in a CI system like Jenkins. When using the option to "ignore" flaky tests the result count reported by Jenkins which parses the `Text.xml` files is wrong in the case that CTest was invoked once without and then again with the option. Since the file is being overwritten the previously passing tests are not mentioned in the statistics anymore. Therefore it would be great of a run triggered with `--rerun-failed` would only extend the existing `Test.xml` result file (eventually toggle this new behavior using a command line option).https://gitlab.kitware.com/cmake/cmake/-/issues/16639STRING TOUPPER and TOLOWER miss diacritic characters2017-10-13T13:17:55-04:00Thiago M. de C. MarquesSTRING TOUPPER and TOLOWER miss diacritic charactersThe following CMake script:
```
function(test command input expected)
string(${command} ${input} result)
if(NOT result STREQUAL expected)
message(SEND_ERROR "string(${command}): \n"
"Input___: ${input} ...The following CMake script:
```
function(test command input expected)
string(${command} ${input} result)
if(NOT result STREQUAL expected)
message(SEND_ERROR "string(${command}): \n"
"Input___: ${input} \n"
"Expected: ${expected}\n"
"Got_____: ${result}")
endif()
endfunction()
set(lower "a á ā è ǐ õ ü ŭ ç ĉ c")
set(upper "A Á Ā È Ǐ Õ Ü Ŭ Ç Ĉ C")
test(TOUPPER ${lower} ${upper})
test(TOLOWER ${upper} ${lower})
```
fails with the following output:
```
CMake Error [...] (message):
string(TOUPPER):
Input___: a á ā è ǐ õ ü ŭ ç ĉ c
Expected: A Á Ā È Ǐ Õ Ü Ŭ Ç Ĉ C
Got_____: A á Ā è Ǐ õ ü ŭ ç ĉ C
CMake Error [...] (message):
string(TOLOWER):
Input___: A Á Ā È Ǐ Õ Ü Ŭ Ç Ĉ C
Expected: a á ā è ǐ õ ü ŭ ç ĉ c
Got_____: a Á ā È ǐ Õ Ü Ŭ Ç Ĉ c
```
**Note**: GitLab's Markdown code blocks seem to not support those characters well too (at least in Preview mode). I'm attaching the original file and output as UTF-8 files:
[string-TOUPPER-unicode.cmake](/uploads/ed96f52170b2d1b0a6e0cc9a32c546c2/string-TOUPPER-unicode.cmake)
[output.txt](/uploads/fa42f1cf59e838080210847782fdae07/output.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/16714Using Intel Fortran on Windows with NMake generator fails to detect the linke...2017-10-13T13:17:55-04:00Javier MartínUsing Intel Fortran on Windows with NMake generator fails to detect the linker versionWhen using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS20...When using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS2008, so the linker used is able to generate and embed a manifest into binaries. However, since the activation of this feature depends on MSVC_VERSION and this variable gets a "wrong", low value, the manifest embedding is not enabled and instead, the linker generates both my out.exe and an out.exe.manifest file. By contrast, if the VS 2008 generator is used instead of the "NMake Makefiles" generator, the rules for manifest embedding are generated.
The problem can be reproduced as follows:
* Environment: Windows computer with Intel Fortran 12.0 with MS Visual Studio 2008 _shell_ - it has link.exe (9.0) but not the corresponding cl.exe (15.0)
* Project: any simple "hello world" Fortran project will do. I am just doing `project(out Fortran)` and then `add_executable(out hello.f90)`.
* Configuration: I configure and generate the project with two generators, "Visual Studio 9 2008" and "NMake Makefiles" (the latter from the command line created by the Intel Fortran-provided equivalent to vcvars.bat)
* Result: the VS project generates out.exe, which has an embedded manifest; while the makefile version generates out.exe _without_ an embedded manifest _and_ an out.exe.manifest alongside it. In order for the latter executable to be usable, the manifest file must either be copied alongside the binary, or manually embedded with a call to mt.exe.
* Expected result: both generators result in executable files with embedded manifests.
I traced the problem to the fact that `Modules/Platforms/Windows-MSVC.cmake` (which is included by `Windows-Intel.cmake`) tests the `MSVC_VERSION` variable (the version of *cl.exe*) and only enables the manifest embedding if it at least 1400, the version of cl that comes with VS 2005.
This variable is defined above in the same file; in this case it is set from the value of the `CMAKE_Fortran_SIMULATE_VERSION` variable, which comes from data extracted from the Intel Fortran compiler by building and running `CMakeFortranCompilerId.F.in`. The problem is that, while Intel Fortran in Windows does report the \_MSC_VER macro, it reports *the same version reported by cl.exe*. Since in my case there is no cl.exe to be found, ifort reports _MSC_VER=1020, which is so old that it is stored by CMake as 1300. Thus, the manifest embedding feature is not enabled.
Since having the Intel Fortran compiler without the MS _C compiler_ is a valid configuration, the condition for the manifest embedding feature should depend on detecting features from the linker itself, not the C compiler.https://gitlab.kitware.com/cmake/cmake/-/issues/16671Codelite projects can't be debugged/launched from Codelite2017-10-13T13:17:55-04:00Timo WiesemannCodelite projects can't be debugged/launched from CodeliteWhen generating a "Codelite - Unix Makefiles" project, I can build everything.
But I cannot launch/debug a project from within Codelite.
It can't find the executable.
In each sub-project's settings the Output File is set to **./$(Proje...When generating a "Codelite - Unix Makefiles" project, I can build everything.
But I cannot launch/debug a project from within Codelite.
It can't find the executable.
In each sub-project's settings the Output File is set to **./$(ProjectName)**, which seems to be **${CMAKE_BINARY_DIR}/${PROJECT_NAME}** (see image).
In my project the binaries are *not* build in the root of **${CMAKE_BINARY_DIR}**.
Stepping through the cmake source I found that in *cmExtraCodeLiteGenerator.cxx* only **EXECUTABLE_OUTPUT_PATH** is queried for the binary output path,
which was always empty for the projects I tried - so it defaulted.
In my project I set them via **CMAKE_RUNTIME_OUTPUT_DIRECTORY**. If I change the code to query that variable first, the output filepath is set correctly.
That would help in my situation, where my binaries are named exactly like the project names.
It won't suffice for i.e the cmake source, where the project is named "CMake" but the executable is named "cmake".
OS: Lubuntu 16.04 LTS CMake version: 3.7.2, clang 3.8.0
![cmake-3.7.2_codelite_generator](/uploads/f3ecb55115e6308c256a94356b590bae/cmake-3.7.2_codelite_generator.png)https://gitlab.kitware.com/cmake/cmake/-/issues/16485Check path length in Windows to be shorter than MAX_PATH2017-10-13T13:17:55-04:00alihaCheck path length in Windows to be shorter than MAX_PATH> In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. [[msdn](https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365247(...> In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. [[msdn](https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath)]
This can cause a problem in complex projects, as I recently experienced it (as a result of this problem, Visual Studio could not find a dependency simply because the path was more than 260 characters).
IMHO, in Windows, when a path longer than MAX_PATH is detected, CMake should at least log a warning if not an error.https://gitlab.kitware.com/cmake/cmake/-/issues/16434ExternalProject had redundant download and extract steps for multi configurat...2017-10-13T13:17:55-04:00Doug CrawfordExternalProject had redundant download and extract steps for multi configuration projectsIn a multi config build the time stamps for each step are independent and saved in the respective config folder under the stamp folder (Debug and Release). This causes the download extract, patch steps to be repeated for each configurat...In a multi config build the time stamps for each step are independent and saved in the respective config folder under the stamp folder (Debug and Release). This causes the download extract, patch steps to be repeated for each configuration. This is a problem for in source builds (BUILD_IN_SOURCE 1) since the whole source tree (and build artifacts) get replaced when the second config is built. In source builds are needed for classic visual studio projects (not cmake based).
Wouldn't it be better to have all the configurations (Debug and Release) share the download, extract, patch steps. Could this be solved by just moving the -mkdir, -download, -update, -patch timestamps to their parent directory so they are shared between all configs?https://gitlab.kitware.com/cmake/cmake/-/issues/16583Missing / inaccurate documentation of INSTALL and DESTDIR2017-10-13T13:17:55-04:00Kacper PlutaMissing / inaccurate documentation of INSTALL and DESTDIRThe documentation of INSTALL() should be improved by a section explaining the correct use of \$ENV{DESTDIR} during the installation time. This is important in order to avoid problems with incorrectly set paths during make install with a...The documentation of INSTALL() should be improved by a section explaining the correct use of \$ENV{DESTDIR} during the installation time. This is important in order to avoid problems with incorrectly set paths during make install with a user specified DESTDIR. The starting point would be: https://cmake.org/pipermail/cmake-developers/2013-January/017810.htmlhttps://gitlab.kitware.com/cmake/cmake/-/issues/16305cpack hangs after installation of project2017-10-13T13:17:55-04:00Adam Updegrovecpack hangs after installation of projectIm on Mac OSX 10.10 and using cmake version 3.5.2 with cpack to create a mac Bundle.
I have used cpack --debug and pack --verbose and found that everything installs fine and then cpack just hangs at:
'CPack Verbose: Package files to: l...Im on Mac OSX 10.10 and using cmake version 3.5.2 with cpack to create a mac Bundle.
I have used cpack --debug and pack --verbose and found that everything installs fine and then cpack just hangs at:
'CPack Verbose: Package files to: location_of_dmg'
This is the step where it creates the dmg. cpack was able to create the dmg no problem with an older version of my project with less files and installed libs. So it seems like cpack is having trouble packaging the larger size? Is there anything I may be missing here.
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/16484BROKEN BOOST support (dynamic setup link to static libs names in visual studio)2017-10-13T13:17:55-04:00Petar PetrovBROKEN BOOST support (dynamic setup link to static libs names in visual studio)In my CMakeLists.txt
```
IF(NOT Boost_SOURCE_DIR)
set(Boost_DEBUG ON)
#TODO set exactly where to take boost from
#set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
#set(BOOST_ROOT "../boost")
set(Boost_USE_STATIC_LIBS OFF)
...In my CMakeLists.txt
```
IF(NOT Boost_SOURCE_DIR)
set(Boost_DEBUG ON)
#TODO set exactly where to take boost from
#set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
#set(BOOST_ROOT "../boost")
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
set(BOOST_ALL_DYN_LINK ON) # force dynamic linking for all libraries
add_definitions(${Boost_LIB_DIAGNOSTIC_DEFINITIONS})
find_package(Boost COMPONENTS serialization REQUIRED)
IF(Boost_FOUND)
message(STATUS "** Boost Include: ${Boost_INCLUDE_DIR}")
message(STATUS "** Boost Libraries: ${Boost_LIBRARY_DIRS}")
message(STATUS "** Boost Link-Libs: ${Boost_LIBRARIES}")
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
ENDIF(Boost_FOUND)
ENDIF(NOT Boost_SOURCE_DIR)
```
Output:
```
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:983 ] _boost_TEST_VERSIONS = 1.62.0;1.62;1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:985 ] Boost_USE_MULTITHREADED = ON
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:987 ] Boost_USE_STATIC_LIBS = OFF
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:989 ] Boost_USE_STATIC_RUNTIME = OFF
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:991 ] Boost_ADDITIONAL_VERSIONS =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:993 ] Boost_NO_SYSTEM_PATHS =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1061 ] Declared as CMake or Environmental Variables:
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1063 ] BOOST_ROOT =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1065 ] BOOST_INCLUDEDIR =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1067 ] BOOST_LIBRARYDIR =
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1069 ] _boost_TEST_VERSIONS = 1.62.0;1.62;1.61.0;1.61;1.60.0;1.60;1.59.0;1.59;1.58.0;1.58;1.57.0;1.57;1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53;1.52.0;1.52;1.51.0;1.51;1.50.0;1.50;1.49.0;1.49;1.48.0;1.48;1.47.0;1.47;1.46.1;1.46.0;1.46;1.45.0;1.45;1.44.0;1.44;1.43.0;1.43;1.42.0;1.42;1.41.0;1.41;1.40.0;1.40;1.39.0;1.39;1.38.0;1.38;1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1162 ] location of version.hpp: C:/Users/p/Documents/NENA/boost_1_59_0/boost/version.hpp
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1186 ] version.hpp reveals boost 1.59.0
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1272 ] guessed _boost_COMPILER = -vc140
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1282 ] _boost_MULTITHREADED = -mt
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1326 ] _boost_RELEASE_ABI_TAG = -
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1328 ] _boost_DEBUG_ABI_TAG = -gd
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1384 ] _boost_LIBRARY_SEARCH_DIRS_RELEASE = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH_boost_LIBRARY_SEARCH_DIRS_DEBUG = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1523 ] Searching for SERIALIZATION_LIBRARY_RELEASE: boost_serialization-vc140-mt-1_59;boost_serialization-vc140-mt;boost_serialization-mt-1_59;boost_serialization-mt;boost_serialization
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:362 ] Boost_LIBRARY_DIR_RELEASE = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib _boost_LIBRARY_SEARCH_DIRS_RELEASE = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1565 ] Searching for SERIALIZATION_LIBRARY_DEBUG: boost_serialization-vc140-mt-gd-1_59;boost_serialization-vc140-mt-gd;boost_serialization-mt-gd-1_59;boost_serialization-mt-gd;boost_serialization-mt;boost_serialization
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:362 ] Boost_LIBRARY_DIR_DEBUG = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib _boost_LIBRARY_SEARCH_DIRS_DEBUG = C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH
[ C:/Program Files/CMake/share/cmake-3.7/Modules/FindBoost.cmake:1635 ] Boost_FOUND = 1
Boost version: 1.59.0
Found the following Boost libraries:
serialization
** Boost Include: C:/Users/p/Documents/NENA/boost_1_59_0
** Boost Libraries: C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib
** Boost Link-Libs: optimized;C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib/boost_serialization-vc140-mt-1_59.lib;debug;C:/Users/p/Documents/NENA/boost_1_59_0/stage/lib/boost_serialization-vc140-mt-gd-1_59.lib
```
However in Visual Studio 2015:
>LINK : fatal error LNK1104: cannot open file 'libboost_serialization-vc140-mt-gd-1_59.lib'https://gitlab.kitware.com/cmake/cmake/-/issues/16669Having executables named "test" causes Ninja generator to generate ambiguous ...2017-10-13T13:17:55-04:00Kris MalfettoneHaving executables named "test" causes Ninja generator to generate ambiguous rules...I first posted this on the users mailing list but thought at this point it was definitely a bug and wanted to report it here. The basic gist is this:
> The code that produces the "# Target aliases." section of the build.ninja seems to ...I first posted this on the users mailing list but thought at this point it was definitely a bug and wanted to report it here. The basic gist is this:
> The code that produces the "# Target aliases." section of the build.ninja seems to try and avoid ambiguities between targets but fails to consider built in cmake targets such as "test,install,install/strip,etc...". This way when executables are named "test" (please note that their target names are both unique and not "test") they cause the ninja generator to create ambiguous targets.
There is a fair bit of description and small example CMakeLists.txt setup to reproduce the problem in this thread: http://public.kitware.com/pipermail/cmake/2017-February/065004.html
In particular steps to reproduce are here: http://public.kitware.com/pipermail/cmake/2017-February/065014.html
Top level CMakeLists.txt:
`
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_subdirectory("subdir")
add_subdirectory("subdir2")
`
Subdir with CMakeLists.txt:
`
add_executable( "Foo.test" foo_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
`
subdir2 with CMakeLists.txt:
`
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Bar.test" COMMAND test )
`
Contents of both source files (obviously in their respective subdirectories):
`
int main( int, char** )
{
return 0;
}
`
If you need any other information please feel to contact me.
Thanking you in advance,
Krishttps://gitlab.kitware.com/cmake/cmake/-/issues/16705cpack: wrong directory permissions of automatically created directories in d...2017-10-13T13:17:55-04:00Bernicpack: wrong directory permissions of automatically created directories in deb build.When building a deb-package the permissions of directories should be 755 according do debian standard but they are 770 if the directories are automatically added. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}.When building a deb-package the permissions of directories should be 755 according do debian standard but they are 770 if the directories are automatically added. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}.