CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-12-31T15:31:15-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/18740GetPrerequisites: Location of dumpbin.exe needs to be updated for Visual Stud...2018-12-31T15:31:15-05:00Craig ScottGetPrerequisites: Location of dumpbin.exe needs to be updated for Visual Studio 2017+The `GetPrerequisites` module has some [embedded search paths](https://gitlab.kitware.com/cmake/cmake/blob/v3.13.2/Modules/GetPrerequisites.cmake#L655) for the `gp_cmd_paths` it should search in when trying to locate the appropriate tool...The `GetPrerequisites` module has some [embedded search paths](https://gitlab.kitware.com/cmake/cmake/blob/v3.13.2/Modules/GetPrerequisites.cmake#L655) for the `gp_cmd_paths` it should search in when trying to locate the appropriate tool. These paths appear to only account for Visual Studio 2015 or older and should be updated for more recent VS versions.https://gitlab.kitware.com/cmake/cmake/-/issues/18473Ninja: Missing build.ninja file on Windows2022-12-14T14:31:28-05:00Sebastian LipponerNinja: Missing build.ninja file on WindowsRunning cmake-3.13.0-rc1-win64 with the attached CMakeLists.txt file and the command line
```
cmake -G "Ninja" -B build .
```
seems to be successful at first. At least, CMake does not fail with an error and claims to have written all ...Running cmake-3.13.0-rc1-win64 with the attached CMakeLists.txt file and the command line
```
cmake -G "Ninja" -B build .
```
seems to be successful at first. At least, CMake does not fail with an error and claims to have written all build files. However, the resulting build directory lacks the `build.ninja` file.
```
cmake_minimum_required(VERSION 3.12)
include_directories( )
file(TOUCH "${CMAKE_CURRENT_BINARY_DIR}/empty.c")
add_executable(main
"${CMAKE_CURRENT_BINARY_DIR}/empty.c"
)
```
Note, that the argument to `include_directories()` is a no-break space character.
[CMakeLists.txt](/uploads/fa85919d50a5b7474a52e757584652ae/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/18296.msi installer does not honour INSTALL_ROOT parameter when previous versions ...2018-08-24T14:48:06-04:00Gordon.msi installer does not honour INSTALL_ROOT parameter when previous versions existWhen I installed a new version with my unattended install command:
`msiexec.exe /qb /i cmake-3.11.1-win64-x64.msi INSTALL_ROOT=C:\CMAKE_3_11_1 ADD_CMAKE_TO_PATH=None `
the installer ignores the INSTALL_ROOT property and installs in ...When I installed a new version with my unattended install command:
`msiexec.exe /qb /i cmake-3.11.1-win64-x64.msi INSTALL_ROOT=C:\CMAKE_3_11_1 ADD_CMAKE_TO_PATH=None `
the installer ignores the INSTALL_ROOT property and installs in the location of a previous installation (C:\CMAKE_2_7_1)https://gitlab.kitware.com/cmake/cmake/-/issues/18120Windows CMake failures with case senstitive folders (Windows 10 April 2018 up...2023-08-13T12:53:59-04:00Ian DayWindows CMake failures with case senstitive folders (Windows 10 April 2018 update)So, had this issue were a new sub-project would continuously rebuild when nothing had changed. ie. In 2017 SLN, F5 after a successful build would re-build it all over again. Was stuck on this for a good day. Enable diagnostics and after ...So, had this issue were a new sub-project would continuously rebuild when nothing had changed. ie. In 2017 SLN, F5 after a successful build would re-build it all over again. Was stuck on this for a good day. Enable diagnostics and after some googling, found the offending issue. For note, I'm cross compiling from same CMake setup in VS2017 and gcc 6.3 under Debian WSL. Here's what Visual Studio says about the issue:
`5>Project is not up-to-date: build input 'c:\git\cambrionix\external\flatbuffers\cmakelists.txt' is missing.`
And sure enough from CMD.EXE in Windows, here's the folder. One DIR with the given filename, and once again with the case fully specified:
```
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>dir c:\git\cambrionix\external\flatbuffers\cmakelists.txt
Volume in drive C has no label.
Volume Serial Number is 6801-D9E9
Directory of c:\git\cambrionix\external\flatbuffers
File Not Found
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>dir C:\git\Cambrionix\external\flatbuffers\CMakeLists.txt
Volume in drive C has no label.
Volume Serial Number is 6801-D9E9
Directory of C:\git\Cambrionix\external\flatbuffers
24/06/2018 11:59 AM 11,495 CMakeLists.txt
1 File(s) 11,495 bytes
0 Dir(s) 31,499,501,568 bytes free
```
It turns out that since the April 2018 update of Windows 10, folders that are created under WSL will automatically have the new case sensitive folder attribute enabled. I'd cloned the specific part from WSL terminal.
I'm not sure where or when CMake decides to lowercase filenames, but it needs to stop. :)
It obviously doesn't do it for other generators, and I can see no good reason to do it for Windows, either now or in the past, regardless of case sensitive filesystem options.
A temporary work-around for this is to disable the case on the folders created under WSL. See: https://www.howtogeek.com/354220/how-to-enable-case-sensitive-folders-on-windows-10/
But this is obviously not a long term solution now that Microsoft have bitten the bullet to allow this.https://gitlab.kitware.com/cmake/cmake/-/issues/18053ccmake for windows using (pd)curses2023-10-11T07:05:39-04:00gegoggigogccmake for windows using (pd)cursesHi,
I tried compiling ccmake using PDCurses for windows. It as simple as just using the PDCurses library instead, with little to none modifications of the source code.
The only issue is that in ccmake.cxx you can't use the signal on con...Hi,
I tried compiling ccmake using PDCurses for windows. It as simple as just using the PDCurses library instead, with little to none modifications of the source code.
The only issue is that in ccmake.cxx you can't use the signal on console resize to trigger the callback. However, if you just remove those lines it compiles and just works (except for resizing.. but that must be solvable without too much hassle).
Is this of any interest to you?https://gitlab.kitware.com/cmake/cmake/-/issues/17889ninja generator compile_commands.json didn't expand pdb path2018-04-09T09:44:59-04:00comicfansninja generator compile_commands.json didn't expand pdb pathwhen creating compile_commands.json with Ninja generator (cmake 3.11), it shows
```json
[
{
"directory": "F:/svn/testco/build",
"command": "C:\\PROGRA~2\\MICROS~2.0\\VC\\bin\\amd64\\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR ...when creating compile_commands.json with Ninja generator (cmake 3.11), it shows
```json
[
{
"directory": "F:/svn/testco/build",
"command": "C:\\PROGRA~2\\MICROS~2.0\\VC\\bin\\amd64\\cl.exe /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 /FoCMakeFiles\\main.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB -c F:\\svn\\testco\\main.cpp",
"file": "F:/svn/testco/main.cpp"
}
]
```
pdb flag shows as : /FdTARGET_COMPILE_PDB
seems this is constructed from cmNinjaTargetGenerator.cxx:864,which didn't include pdb pathhttps://gitlab.kitware.com/cmake/cmake/-/issues/17783Windows now has per-directory case sensitivity2018-03-05T16:57:43-05:00Ben BoeckelWindows now has per-directory case sensitivityNot sure how much this affects CMake on Windows, but [here's a blog post](https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/).Not sure how much this affects CMake on Windows, but [here's a blog post](https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/).https://gitlab.kitware.com/cmake/cmake/-/issues/17758ExternalProject_Add build files always in the wrong spot for Windows?2018-09-25T17:45:14-04:00Patrick AveryExternalProject_Add build files always in the wrong spot for Windows?Hi there,
I'm using MSVC 2017 on a Windows 10 computer, and cmake 3.10.1. For some reason, my ExternalProject_Add keeps on putting the build files in a different directory than it should be. I can't figure out if the problem is on my en...Hi there,
I'm using MSVC 2017 on a Windows 10 computer, and cmake 3.10.1. For some reason, my ExternalProject_Add keeps on putting the build files in a different directory than it should be. I can't figure out if the problem is on my end or not.
Below is the source code for the ExternalProject_Add (along with some messages being printed).
```
set(molequeue_source "${CMAKE_CURRENT_SOURCE_DIR}/molequeue")
set(molequeue_build "${CMAKE_CURRENT_BINARY_DIR}/molequeue")
message("CMAKE_CURRENT_SOURCE_DIR is ${CMAKE_CURRENT_SOURCE_DIR}")
message("CMAKE_CURRENT_BINARY_DIR is ${CMAKE_CURRENT_BINARY_DIR}")
unset(_deps)
if(BUILD_MOLEQUEUE_UIT)
set(_deps "kdsoap")
set(_uit "ON")
else()
set(_uit "OFF")
endif()
message("molequeue_source is ${molequeue_source}")
message("molequeue_build is ${molequeue_build}")
message("OpenChemistry_DEFAULT_ARGS is ${OpenChemistry_DEFAULT_ARGS}")
message("OpenChemistry_THIRDPARTYLIBS_ARGS is ${OpenChemistry_THIRDPARTYLIBS_ARGS}")
ExternalProject_Add(molequeue
SOURCE_DIR ${molequeue_source}
BINARY_DIR ${molequeue_build}
CMAKE_CACHE_ARGS
${OpenChemistry_DEFAULT_ARGS}
${OpenChemistry_THIRDPARTYLIBS_ARGS}
-DMoleQueue_USE_EZHPC_UIT:BOOL=${_uit}
DEPENDS
${_deps}
)
message("FORCE_STEP is ${FORCE_STEP}")
message("FORCE_STEP_ARGS is ${FORCE_STEP_ARGS}")
message("CMAKE_CURRENT_BINARY_DIR is ${CMAKE_CURRENT_BINARY_DIR}")
if(FORCE_STEP)
ExternalProject_Add_Step(molequeue forcebuild
COMMAND ${CMAKE_COMMAND} -E echo "Force build of molequeue"
${FORCE_STEP_ARGS}
ALWAYS 1)
endif()
```
Below is the text from running cmake.
```
D:\Users\patrick\src\vs2017\openchemistry\build>cmake .. -G "NMake Makefiles" -DCMAKE_PREFIX_PATH=D:/opt/Qt/Qt5.9.2/5.9.2/msvc2017_64 -DUSE_VTK=ON
-- The CXX compiler identification is MSVC 19.12.25835.0
-- Check for working CXX compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMAKE_CURRENT_SOURCE_DIR is D:/Users/patrick/src/vs2017/openchemistry
CMAKE_CURRENT_BINARY_DIR is D:/Users/patrick/src/vs2017/openchemistry/build
molequeue_source is D:/Users/patrick/src/vs2017/openchemistry/molequeue
molequeue_build is D:/Users/patrick/src/vs2017/openchemistry/build/molequeue
OpenChemistry_DEFAULT_ARGS is -DBUILD_SHARED_LIBS:BOOL=ON;-DCMAKE_PREFIX_PATH:PATH=D:/Users/patrick/src/vs2017/openchemistry/build/prefix;D:/opt/Qt/Qt5.9.2/5.9.2/msvc2017_64;-DCMAKE_INSTALL_PREFIX:PATH=D:/Users/patrick/src/vs2017/openchemistry/build/prefix;-DCMAKE_BUILD_TYPE:STRING=Debug;-DQt5_DIR:PATH=D:/opt/Qt/Qt5.9.2/5.9.2/msvc2017_64/lib/cmake/Qt5;-DBUILD_DOCUMENTATION:BOOL=OFF;-DENABLE_TESTING:BOOL=OFF;-DUSE_VTK:BOOL=ON
OpenChemistry_THIRDPARTYLIBS_ARGS is
FORCE_STEP is build
FORCE_STEP_ARGS is DEPENDEES;configure;DEPENDERS;build
CMAKE_CURRENT_BINARY_DIR is D:/Users/patrick/src/vs2017/openchemistry/build
-- Configuring done
-- Generating done
-- Build files have been written to: D:/Users/patrick/src/vs2017/openchemistry/build
```
Now, we can see from the cmake code the line: `BINARY_DIR ${molequeue_build}`. `BINARY_DIR` is clearly being set to `D:/Users/patrick/src/vs2017/openchemistry/build/molequeue`.
But then when I run `nmake` (or `nmake VERBOSE=1` in this case), it always generates the build files in `D:/Users/patrick/src`. I have no idea why.
```
D:\Users\patrick\src\vs2017\openchemistry\build>nmake VERBOSE=1
Microsoft (R) Program Maintenance Utility Version 14.12.25835.0
Copyright (C) Microsoft Corporation. All rights reserved.
"C:\Program Files\CMake\bin\cmake.exe" -HD:\Users\patrick\src\vs2017\openchemistry -BD:\Users\patrick\src\vs2017\openchemistry\build --check-build-system CMakeFiles\Makefile.cmake 0
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_progress_start D:\Users\patrick\src\vs2017\openchemistry\build\CMakeFiles D:\Users\patrick\src\vs2017\openchemistry\build\CMakeFiles\progress.marks
"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe" -f CMakeFiles\Makefile2 /nologo - all
"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe" -f CMakeFiles\molequeue.dir\build.make /nologo -L CMakeFiles\molequeue.dir\depend
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_depends "NMake Makefiles" D:\Users\patrick\src\vs2017\openchemistry D:\Users\patrick\src\vs2017\openchemistry D:\Users\patrick\src\vs2017\openchemistry\build D:\Users\patrick\src\vs2017\openchemistry\build D:\Users\patrick\src\vs2017\openchemistry\build\CMakeFiles\molequeue.dir\DependInfo.cmake --color=
Dependee "D:\Users\patrick\src\vs2017\openchemistry\build\CMakeFiles\molequeue.dir\DependInfo.cmake" is newer than depender "D:/Users/patrick/src/vs2017/openchemistry/build/CMakeFiles/molequeue.dir/depend.internal".
Dependee "D:/Users/patrick/src/vs2017/openchemistry/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "D:/Users/patrick/src/vs2017/openchemistry/build/CMakeFiles/molequeue.dir/depend.internal".
Scanning dependencies of target molequeue
"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe" -f CMakeFiles\molequeue.dir\build.make /nologo -L CMakeFiles\molequeue.dir\build
[ 1%] Creating directories for 'molequeue'
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory D:/Users/patrick/src/vs2017/openchemistry/molequeue
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory D:/Users/patrick/src/vs2017/openchemistry/build/molequeue
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/tmp
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src/molequeue-stamp
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E make_directory D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E touch D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src/molequeue-stamp/molequeue-mkdir
[ 2%] No download step for 'molequeue'
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E echo_append
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E touch D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src/molequeue-stamp/molequeue-download
[ 3%] No update step for 'molequeue'
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E echo_append
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E touch D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src/molequeue-stamp/molequeue-update
[ 4%] No patch step for 'molequeue'
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E echo_append
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E touch D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src/molequeue-stamp/molequeue-patch
[ 5%] Performing configure step for 'molequeue'
cd D:\Users\patrick\src\vs2017\openchemistry\build\molequeue
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -CD:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/tmp/molequeue-cache-Debug.cmake "-GNMake Makefiles" D:/Users/patrick/src/vs2017/openchemistry/molequeue
loading initial cache file D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/tmp/molequeue-cache-Debug.cmake
Re-run cmake no build system arguments
-- The C compiler identification is MSVC 19.12.25835.0
-- The CXX compiler identification is MSVC 19.12.25835.0
-- Check for working C compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.16.2.windows.1")
-- Determined Source Version : 0.8.0-31-g2aab341
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Success
-- Adding Qt 5 directory: D:/opt/Qt/Qt5.9.2/5.9.2/msvc2017_64/bin
-- Configuring done
CMake Warning (dev) in molequeue/app/CMakeLists.txt:
Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files.
Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
For compatibility, CMake is excluding the GENERATED source file(s):
"D:/Users/patrick/src/molequeue/app/ui_aboutdialog.h"
"D:/Users/patrick/src/molequeue/app/ui_addqueuedialog.h"
"D:/Users/patrick/src/molequeue/app/ui_advancedfilterdialog.h"
"D:/Users/patrick/src/molequeue/app/ui_importprogramdialog.h"
"D:/Users/patrick/src/molequeue/app/ui_importqueuedialog.h"
"D:/Users/patrick/src/molequeue/app/ui_jobtablewidget.h"
"D:/Users/patrick/src/molequeue/app/ui_localqueuewidget.h"
"D:/Users/patrick/src/molequeue/app/ui_logwindow.h"
"D:/Users/patrick/src/molequeue/app/ui_mainwindow.h"
"D:/Users/patrick/src/molequeue/app/ui_openwithmanagerdialog.h"
"D:/Users/patrick/src/molequeue/app/ui_programconfiguredialog.h"
"D:/Users/patrick/src/molequeue/app/ui_queuemanagerdialog.h"
"D:/Users/patrick/src/molequeue/app/ui_queuesettingsdialog.h"
"D:/Users/patrick/src/molequeue/app/ui_remotequeuewidget.h"
"D:/Users/patrick/src/molequeue/app/ui_templatekeyworddialog.h"
from processing by AUTOMOC. If any of the files should be processed, set
CMP0071 to NEW. If any of the files should not be processed, explicitly
exclude them by setting the source file property SKIP_AUTOMOC:
set_property(SOURCE file.h PROPERTY SKIP_AUTOMOC ON)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Generating done
-- Build files have been written to: D:/Users/patrick/src
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E touch D:/Users/patrick/src/vs2017/openchemistry/build/molequeue-prefix/src/molequeue-stamp/molequeue-configure
cd D:\Users\patrick\src\vs2017\openchemistry\build
[ 6%] Performing forcebuild step for 'molequeue'
echo >nul && "C:\Program Files\CMake\bin\cmake.exe" -E echo "Force build of molequeue"
Force build of molequeue
[ 7%] Performing build step for 'molequeue'
cd D:\Users\patrick\src\vs2017\openchemistry\build\molequeue
"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe"
Microsoft (R) Program Maintenance Utility Version 14.12.25835.0
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.
NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
```
Note the line near the bottom: `-- Build files have been written to: D:/Users/patrick/src`. And then the build fails because it can't find the Makefile.
Does anyone have any idea what the problem could be here? I can't figure it out.
I can confirm that there are no CMakeCache.txt files in my tree when I run `cmake`.https://gitlab.kitware.com/cmake/cmake/-/issues/17739CMake on Windows does not see source directories 'created' by MKLINK during t...2018-02-19T14:58:11-05:00Venca BCMake on Windows does not see source directories 'created' by MKLINK during the 'configure' phase.CMake on Windows ~~7~~ (confirmed on 7, 8.x) does not see source directories 'created' by MKLINK during the 'configure' phase.
**How to reproduce?**
1. Lets have 'SomeLib' CMake project
1. Create another simple CMake project
2. To such...CMake on Windows ~~7~~ (confirmed on 7, 8.x) does not see source directories 'created' by MKLINK during the 'configure' phase.
**How to reproduce?**
1. Lets have 'SomeLib' CMake project
1. Create another simple CMake project
2. To such project add following command (which will create symlink during the configure phase)
`EXECUTE_PROCESS( COMMAND "cmd.exe" "/K" "mklink" "/D" "${CMAKE_CURRENT_SOURCE_DIR}\\SomeLib C:\\Somepath\\SomeLib" WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" )`
3. Then `add_subdirectory( SomeLib )` into it.
4. Let CMake generate buidsystem in this newly created project
or
1. Download attached sample project [CMakeSymlinkIssueSample.7z](/uploads/f6ac24f5a8a5f3f39f9db60ac9eb10bd/CMakeSymlinkIssueSample.7z)
2. Go to the CMakeSymlinkIssueSample/CMakeSymlinkIssueProject
3. Run the build.cmd
**What happens?**
CMake will complain about nonexisting 'SomeLib' directory.
**What is expected?**
CMake should should enter to this newly symlinked subdirectory.
**Observations**
- This 'wrong' behavior is NOT observed on Linux systems.
- When I call CMake for second time, everything works well.
- The MKLINK does not fail, it asks for admin privileges when required.
- The add_subdirectory( SomeLib ) is not the only one which fails, also `IF(EXISTS SomeLib)` and `IF(IS_SYMLINK SomeLib)` does not work as expected.https://gitlab.kitware.com/cmake/cmake/-/issues/17726CPack with NSIS - Allow disabling Components page in non-monolithic installat...2018-02-09T10:41:03-05:00Alexander ShaduriCPack with NSIS - Allow disabling Components page in non-monolithic installationsSometimes, it is needed to use CPACK_COMPONENTS_ALL to install certain components only (especially when using CPACK_PROJECT_CONFIG_FILE). For this to work, CPACK_MONOLITHIC_INSTALL must be false.
However, all these components may be inte...Sometimes, it is needed to use CPACK_COMPONENTS_ALL to install certain components only (especially when using CPACK_PROJECT_CONFIG_FILE). For this to work, CPACK_MONOLITHIC_INSTALL must be false.
However, all these components may be internal so the user should not see the components at all.
Please add a CPack variable to control this - to avoid adding a Components page to .nsi file.
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/17725FindVCRedist: Add a find module to locate vcredist_(arch).exe2018-02-15T11:17:59-05:00Alexander ShaduriFindVCRedist: Add a find module to locate vcredist_(arch).exeCurrently, including InstallRequiredSystemLibraries automatically installs runtime dlls locally (when used with MSVC).
However, the recommended way to install the VC dlls is to use vcredist. Helpfully, InstallRequiredSystemLibraries sets...Currently, including InstallRequiredSystemLibraries automatically installs runtime dlls locally (when used with MSVC).
However, the recommended way to install the VC dlls is to use vcredist. Helpfully, InstallRequiredSystemLibraries sets MSVC_REDIST_DIR so that VC-supplied vcredist can be easily found and used. However, when using vcredist for system installation of dlls, the locally installed dlls should no longer be used. It is quite difficult to get rid of them, though.
I propose a switch (a variable) which disables actual installation of these dlls, but still sets all the needed variables so that users can create their own install() rules, if needed.https://gitlab.kitware.com/cmake/cmake/-/issues/17672cmake.exe clears console input buffer2018-11-15T04:19:51-05:00Bjoern Thielcmake.exe clears console input bufferPasting a stack of commands into the Windows 'Command Prompt' console e.g.
```
cmake -version
echo Hallo
```
results in unexpected behavior: Everything beyond the first `cmake.exe ...` command is discarded.
This comes from `BasicConsole...Pasting a stack of commands into the Windows 'Command Prompt' console e.g.
```
cmake -version
echo Hallo
```
results in unexpected behavior: Everything beyond the first `cmake.exe ...` command is discarded.
This comes from `BasicConsoleBuf.sync()` implementation calling `::FlushConsoleInputBuffer(m_hInput)`.
But according to http://en.cppreference.com/w/cpp/io/basic_streambuf/pubsync `sync()` shouldn't do that.
Instead it should reread into `m_ibuffer` similar to what we find in `underflow()`.https://gitlab.kitware.com/cmake/cmake/-/issues/17600CMAKE_DL_LIBS should contain "dl" on MINGW2022-09-21T14:37:07-04:00Sandro ManiCMAKE_DL_LIBS should contain "dl" on MINGWI've noticed while cross-compiling libzip to windows using Fedora's mingw toolchain that CMAKE_DL_LIBS is empty (which caused the build to failure with undefined references to dlopen & co.). I believe that CMAKE_DL_LIBS should contain dl...I've noticed while cross-compiling libzip to windows using Fedora's mingw toolchain that CMAKE_DL_LIBS is empty (which caused the build to failure with undefined references to dlopen & co.). I believe that CMAKE_DL_LIBS should contain dl. Patch attached.
[cmake-mingw-dl.patch](/uploads/a21194391caa841d30b252229e27c7a7/cmake-mingw-dl.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/17593WORKING_DIRECTORY dosen't work with Visual studio 20172019-05-28T22:40:17-04:00AIT BEN MOUHWORKING_DIRECTORY dosen't work with Visual studio 2017WORKING_DIRECTORY in CUSTOM_COMMAND dosen't work with visual studio 2017, it used to work in the previous version of VS but now canno't redirect to the desired directory as this option is ignored in CUSTOM_COMMAND.
-----Context--------
...WORKING_DIRECTORY in CUSTOM_COMMAND dosen't work with visual studio 2017, it used to work in the previous version of VS but now canno't redirect to the desired directory as this option is ignored in CUSTOM_COMMAND.
-----Context--------
When trying to change directory in order to run a commands in different Drive WORKING_DIRECTORY has no effect (path C://path1 --to--> D://path2 )
https://gitlab.kitware.com/cmake/cmake/-/issues/17592ExternalProject: CMake ignores proxy settings on Windows2018-05-21T09:56:40-04:00szychowsExternalProject: CMake ignores proxy settings on WindowsWhen behind a proxy and HTTPS_PROXY variable is not set CMake will not download files using ExternalProject_Add.
While this environment variable is standard on Linux, on Windows proxy is usually set up by Internet Explorer settings.
One ...When behind a proxy and HTTPS_PROXY variable is not set CMake will not download files using ExternalProject_Add.
While this environment variable is standard on Linux, on Windows proxy is usually set up by Internet Explorer settings.
One workaround is to download the file by using Powershell, which detects proxy settings and downloads the file.
Minimal example - computer needs to be behind proxy:
```
cmake_minimum_required(VERSION 3.1)
project(proxy_fail_example)
include(ExternalProject)
ExternalProject_Add(
gtest
URL https://github.com/google/googletest/archive/release-1.8.0.zip
URL_HASH SHA256=f3ed3b58511efd272eb074a3a6d6fb79d7c2e6a0e374323d1e6bcbcc1ef141bf
DOWNLOAD_NAME googletest-1.8.0.zip
DOWNLOAD_DIR ${CMAKE_SOURCE_DIR}
PREFIX ${CMAKE_CURRENT_BINARY_DIR}/gtest
INSTALL_COMMAND ""
CMAKE_ARGS -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
)
```
When building the project with:
cmake --build . --config Debug
CMake will try to download the file, but it will just timeout.
I tested and reproduced it on CMake 3.1 and 3.10.1, probably other versions have the same problem.https://gitlab.kitware.com/cmake/cmake/-/issues/17591Error - The system is: Windows - 10.0.16299 - AMD642018-10-18T15:46:34-04:00Chaplin WilliamsError - The system is: Windows - 10.0.16299 - AMD64I constantly receive this error when I try to build using CMake. I am using msvc 2017 and Windows 10. Regardless of the project I attempt to build, CMake fails to successfully build. the error in the CMake GUI is Debug;Release;MinSizeRel...I constantly receive this error when I try to build using CMake. I am using msvc 2017 and Windows 10. Regardless of the project I attempt to build, CMake fails to successfully build. the error in the CMake GUI is Debug;Release;MinSizeRel;RelWithDebInfo and thew log file has The system is: Windows - 10.0.16299 - AMD64 in it.
I am trying to build CGAL, and Yaml.
Can assistance be given to address this?
Thank you.
Chaplinhttps://gitlab.kitware.com/cmake/cmake/-/issues/17566Windows container: CMake Error: Remove failed on file (PDB)2021-11-24T15:45:34-05:00Patrick EinheberWindows container: CMake Error: Remove failed on file (PDB)When running CMake 3.10.0 in git bash 2.15.1.2 inside a Windows 2016 Server container (Docker Community 17.09.1-ce-win42 (14687)), I get the following:
CMake Error: Remove failed on file: C:/mypath/morepath/CMakeFiles/CMakeTmp/Debug/cmT...When running CMake 3.10.0 in git bash 2.15.1.2 inside a Windows 2016 Server container (Docker Community 17.09.1-ce-win42 (14687)), I get the following:
CMake Error: Remove failed on file: C:/mypath/morepath/CMakeFiles/CMakeTmp/Debug/cmTC_cbda2.pdb: System Error: No such file or directory
Which eventually leads to:
CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.12.25827/bin/Hostx86/x86/cl.exe"
is not able to compile a simple test program.
It fails with the following output:
...
LINK : fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006E7)' [C:\mypath\morepath\CMakeFiles\CMakeTmp\cmTC_cbda2.vcxproj]
However, I can successfully run this command and find the file:
dir C:/mypath/morepath/CMakeFiles/CMakeTmp/Debug/cmTC_cbda2.pdb
But not:
ls -l C:/mypath/morepath/CMakeFiles/CMakeTmp/Debug/cmTC_cbda2.pdbhttps://gitlab.kitware.com/cmake/cmake/-/issues/17384Add support for Flang on Windows2019-08-09T09:44:29-04:00Isuru FernandoAdd support for Flang on WindowsI'm trying to build Flang on Windows here, https://github.com/xoviat/flang/pull/2.
Flang has 2 components. The frontend `flang.exe` which is built first https://github.com/flang-compiler/clang and then the actual flang drivers `flang1.ex...I'm trying to build Flang on Windows here, https://github.com/xoviat/flang/pull/2.
Flang has 2 components. The frontend `flang.exe` which is built first https://github.com/flang-compiler/clang and then the actual flang drivers `flang1.exe`, `flang2.exe` and the Fortran runtime libraries. Frontend is built successfully.
When building the drivers, I do, `cmake -G"NMake Makefiles" -DCMAKE_CXX_COMPILER=clang_cl -DCMAKE_C_COMPILER=clang_cl -DCMAKE_Fortran_COMPILER=flang ..` with Visual Studio 2015 amd64 activated. Note that this Fortran compiler is an incomplete one. Executables `flang1.exe` and `flang2.exe` are built successfully and then Fortran compiler is almost complete. (There are some linking issues when I try a hello-world.f90 program, but that's probably not related to the problem below)
When creating `flang_static.lib` which has Fortran sources, Fortran sources are compiled correctly, but when linking the object files together it fails in the `Building fortran static library flang_static.lib` step. This is because this tries to link using (contents of "link.txt" below)
```
"" qc ..\..\lib\flang_static.lib /machine:x64 CMakeFiles\flang_static.dir\abort3f.c.obj ... "" ..\..\lib\flang_static.lib
```
This is not using Microsoft's link.exe program and `qc` seems to be coming from https://github.com/Kitware/CMake/blob/b8fc447c1df34eeca1d66acd0e17ca743256d6c2/Modules/CMakeCInformation.cmake#L179 where `CMAKE_AR` is the first `""` in the command above.
I tried using `CMake-3.10.0-rc3` and `CMake-3.9.3` and there's no difference.
Please let me know if you need any more details.https://gitlab.kitware.com/cmake/cmake/-/issues/17372CodeBlocks: Drive letter missing on Windows2017-10-25T09:54:52-04:00fenugrecCodeBlocks: Drive letter missing on WindowsOn Windows, there is some minor inconsistency in treating a leading backspace '\' character for the source path, when using the "CodeBlocks + minGW makefile" generator.
Example project structure:
```
d:\dev\builddir\ (empty; we run cm...On Windows, there is some minor inconsistency in treating a leading backspace '\' character for the source path, when using the "CodeBlocks + minGW makefile" generator.
Example project structure:
```
d:\dev\builddir\ (empty; we run cmake + make from here)
d:\projects\srcdir\ (project source repo)
```
from the CLI, running
`d:\dev\builddir> cmake-gui \projects\srcdir`
will generate correct makefiles which work as intended, but a broken .cbp file that has relative paths for every source file, (in the .cbp XML, they are noted as `<Unit filename="/projects/srcdir/.....">` .
These paths are then appended by CodeBlocks to the builddir absolute path. This of course results in an unusable .cbp project file where none of the source files can be located.
The obvious workaround is to instead use `cmake-gui d:\projects\srcdir` with the full absolute path, but I believe the first form is correct and should be treated as an absolute path, just as the windows CLI does.
I have a minimal test case uploaded here:
https://gitlab.kitware.com/fenugrec/cmake_tests/tree/master/cbp_gen/orig_srchttps://gitlab.kitware.com/cmake/cmake/-/issues/17258find_package() variables should be case-insensitive2017-09-11T13:12:38-04:00Robert Daileyfind_package() variables should be case-insensitiveWhen doing `find_package(Foo CONFIG)`, predefined variables will follow the pattern `Foo_FIND_COMPONENTS`. If I change the initial call to use `foo`, then the variables become `foo_FIND_COMPONENTS`. This is error prone and IMHO I think t...When doing `find_package(Foo CONFIG)`, predefined variables will follow the pattern `Foo_FIND_COMPONENTS`. If I change the initial call to use `foo`, then the variables become `foo_FIND_COMPONENTS`. This is error prone and IMHO I think the variables should be all-upper-case. So no matter what case the user chooses when they call `find_package()`, the config package scripts get the same variables. Furthermore, this makes sense given that the config file search behavior is also case insensitive. So given both scenarios mentioned previously, you'd get `FOO_FIND_COMPONENTS` in both.
For backward compatibility, you can continue to define the verbatim-case versions of those variables.