B. Eckles B. Eckles - 1 month ago 20
Bash Question

How are CMake execute_process commands run?

I've got the following lines in my CMakeLists.txt file. I'm running CMake 3.5.2 on Windows 7, and using Visual Studio 12 2013 as the generator with "Use default native compilers" checked in the gui.

find_path(FORTRAN_DIR NAMES cdll.cpp fdll.f90 Makefile PATHS ../source)
execute_process(COMMAND make
WORKING_DIRECTORY ${FORTRAN_DIR})


This runs just fine.

But exactly how is it being run?? It's on Windows!

I've compiled the Makefile via MSYS2 (MinGW) on Windows before, but if that's what CMake is using, then I'm not sure how it knows to do that.

Edit: I put
execute_process(COMMAND uname -a)
into the CMakeLists.txt file and got
MSYS_NT-6.1 MYCOMPUTERNAMEHERE 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys
. So I guess that answers that it's being run through MSYS... but how does CMake know to do this?


The documentation says:

"CMake executes the child process using operating system APIs directly. All arguments are passed VERBATIM to the child process. No intermediate shell is used, so shell operators such as > are treated as normal arguments."

But I don't understand what that means, especially considering that if I use the following line, I get
/usr/bin/make
as the output:

execute_process(COMMAND which make)


What is happening, and/or how can I figure out what environment/shell/whatever these commands are being run in?

Answer

CMake comes with Kitware's OS abstraction/detection library kwsys:

KWSys provides a platform-independent API to many common system features that are implemented differently on every platform.

The execute_process() magic is happening in ProcessWin32.c using CreateProcessW() or ProcessUNIX.c using execvp() depending of which version of CMake you are using.

So - as @Tsyvarev has commented - your behavior could either be the Win32/64 version of CMake with MinGW/MSYS in the PATH environment (finding the Unix specific commands given) or the MinGW32/64 version of CMake run from MSYS.

Also you may consider the use of something like the FindUnixCommands to get absolute paths to the Unix tools in question.

Reference

Comments