Building tbb port is certain configurations goes into infinite loop, endlessly creating subdirectories.
Notably this is triggered if Visual Studio is opened at vcpkg root.
Environment
To Reproduce
In ports\tbb execute a command analogous to the following twice:
"C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\INTPREVIEW\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_INSTALL_PREFIX:PATH="D:\Repos\vcpkg\ports\tbb\out\install\x64-Debug" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/IntPreview/VC/Tools/MSVC/14.25.28508/bin/HostX64/x64/cl.exe" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/IntPreview/VC/Tools/MSVC/14.25.28508/bin/HostX64/x64/cl.exe" -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\INTPREVIEW\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\Repos\vcpkg\ports\tbb"
Expected behavior
Build ends promptly.
Actual behavior
cmake goes into infinite loop creating nested directories D:\Repos\vcpkg\ports\tbb\src\src\src\....
Hi @LukaszMendakiewicz, thanks for reporting this issue.
First, I don't understand why you run cmake command with this path.
Second, this CMakeLists.txt should be copied to the tbb source path and executed, and only valid on that path[1].
Third, the cause of the recursive creation path exists in CMakeLists.txt:
file(GLOB SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/*)
file(COPY ${SOURCES} DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/src)
${CMAKE_CURRENT_SOURCE_DIR}in _VCPKG_PATH/ports/tbb_ is definitely _VCPKG_PATH/ports/tbb_, so cause cmake to recursively create the path and copy all files in that path.
[1]. https://github.com/microsoft/vcpkg/blob/master/ports/tbb/portfile.cmake#L12
The command I pasted above is run automatically by the Visual Studio CMake integration when you open vcpkg as a Folder in Visual Studio.
It would be great if using Visual Studio on a project including vcpkg would not cause the latter to explode :).
@LukaszMendakiewicz vcpkg has a set of independent running processes, and currently cannot be accessed by other projects. So I suggest you use powershell / bash to install ports and use them through the vcpkg toolchain[1].
[1]. https://github.com/microsoft/vcpkg/blob/master/docs/examples/installing-and-using-packages.md#step-2-use
I understand that, and I do not intend to "build" vcpkg from Visual Studio. But the problem is hit as a result of attempting to use a project that is using vcpkg in Visual Studio and embeds vcpkg as submodule. For example given a project structure:
src/
...
include/
...
contrib/
vcpkg [submodule]
README.md
Should the project be cloned recursively with vcpkg expanded at contrib directory, and the root folder opened in Visual Studio, then vcpkg will be "in scope" for Visual Studio processing and hit this problem.
Hello. While trying to completely delete vcpkg from my system I've realized that similar bug happened to me. I cannot delete vcpkg/ports/tbb directory, because directory depth looks infinite. I've even tried hack described here [], but it does not work. Deleting lasts forever...
I am not an experienced user. This error must have occurred when I installed Theia (:x64-windows) with the necessary dependencies. The installation was successful, only now when trying to remove vcpkg the problem became apparent.
I still do not know what caused this issue, but I solved problemm (deleted ports dir) with bash command:
rm -rfd path_to_problematic_dir
To all those who get a similar bug, I remind you that the removal using Windows Explorer, the RemoveItem command in Powershell or Robocopy with the / purge flag - all approaches failed.
I also am having this problem, noticed after find -name <?> stopped working in my repo. I've had no luck deleting the offending directories with bash, cmd, explorer, and so on.
@klech86 @dubois Can you please open a new issue to report that?
Thanks.
Most helpful comment
I still do not know what caused this issue, but I solved problemm (deleted ports dir) with bash command:
rm -rfd path_to_problematic_dirTo all those who get a similar bug, I remind you that the removal using Windows Explorer, the RemoveItem command in Powershell or Robocopy with the / purge flag - all approaches failed.