Invoke CMake from within the build directory

[m-j-w]

Currently, cmake is invoked from the current working directory of VS Code, which is on my platform (windows) the C:\Program Files... directory.

This bears subtle problems: When trying to build with MSYS2 or Cygwin, the argument to cmake --build <directory> --target ... uses backslashes as subdirectory delimiters. That of course doesn't work with MSYS2/Cygwin.
Running cmake from within the build directory makes the explicit definition of the build directory as argument redundant, meaning a cmake --build . --target ... (note the dot) would be a portable solution.

I've pretty much no experience with typescript, but giving the child_process.spawn a third argument with key 'cwd' might do the trick.

[vector-of-bool]

Hmm... What version of CMake are you using? I'd think it would parse the backslashes properly.

[m-j-w]

I think Cmake isn't the problem there, it's the shell treating the backslash as escape character. CMake also somewhat assumes to work in a Unix-like environment. Cygwin and MSYS2 would have a command line to perform the proper translation of a single path, but that doesn't work in that case easily. Cygwin and MSYS2 always pose many problems due to that weird mixture of directory delimiters... Hence the issue.

Oh, and the version:

❱❱ cmake --version
cmake version 3.6.2
❱❱ uname -a
MINGW64_NT-10.0 XXXXX 2.6.0(0.304/5/3) 2016-09-07 20:45 x86_64 Msys

[MinnieTheMoocher]

I second the suggestion to adjust the folder inside which cmake gets called
to minimize the number of arguments that need to be passed to it.
It just makes things simpler.

[vector-of-bool]

I'm honestly confused about what could be happening. I'm fairly certain that the shell never sees the CMake command I invoke (and is rather going straight to CreateProcess). The CMake build you are using is the official one from cmake.org? Or is it an MSYS/Cygwin variant?

Either way, just invoking CMake from the build directory will be insufficient when I need to pass in file paths as other arguments.

[m-j-w]

The CMake I'm using in that case belongs to the MSYS/Cygwin environment. Only that way it can provide all the generators and finds to correct configuration. (those differ per OS).

Windows CMake using MSVC toolchain:

[vscode] Executing cmake command: cmake --build w:\Codebase\pieces/build --target ALL_BUILD --config Debug -- /m /property:GenerateFullPaths=true
Microsoft (R)-Buildmodul, Version 14.0.25420.1
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
...

Now, for the MinGW/Cygwin toolchains, my latest solution involves a small batch file, which simply invokes the bash to invoke the correct cmake including the correct path environment variable:

@ECHO OFF
SET PATH=C:\msys64\mingw64\bin;C:\msys64\usr\bin;%PATH%
echo cmake -G"Unix Makefiles" %* > C:\temp\cmake_cmd.sh
bash.exe /c/temp/cmake_cmd.sh

In that, I'm sending the arguments to a file, since I had originally difficulties with not correctly ""-encapsulated arguments, like the generator name. Configuring works fine this way, but building gives in that file containing the temporarily dumped arguments

cmake -G"Unix Makefiles" --build w:\Codebase\pieces/build --target help 

and running that gives

CMake Error: The source directory "C:/Program Files (x86)/Microsoft VS Code/help" does not exist.

Note that the directory "C:/Program Files (x86)/Microsoft VS Code" is the working directory of VS Code.

I'd expect running a cmake say via ssh on a remote linux to give similar problems.

[vector-of-bool]

Ah! In this case, I'm guessing CMake itself is parsing the \x as escape sequences. I'll poke around with some solutions

[vector-of-bool]

Should be fixed in next release