why can't wsl be called from cmake scripts? - cmake

I have bash scripts that generate c++ files and I would like to call them from an add_custom_command() in cmake. On windows, I'd like to call the bash script through wsl (windows subsytem for linux). cmake configures fine (finding wsl.exe), but on build it complains that:
'C:\Windows\System32\wsl.exe' is not recognized as an internal or external command,
Here is a simple cmake script to recreate. It succeeds in a linux environment (including wsl), but fails in the native windows environment.
cmake_minimum_required(VERSION 3.7)
project(WhyNotWSL)
set(source ${CMAKE_SOURCE_DIR}/Input/main.cpp)
set(target generated.cpp )
if (WIN32)
find_program(WSL wsl)
message("WSL is ${WSL}")
set (command ${WSL} cp ${source} ${target})
else()
set (command cp ${source} ${target})
endif()
message("command is ${command}")
add_custom_target( ${target} )
add_custom_command(
OUTPUT ${target}
COMMAND ${command}
DEPENDS ${source}
COMMENT "Generated ${target}"
)
add_custom_target(p ALL
DEPENDS ${target}
)
add_executable(hello ${target})
The following output is from cmake configure:
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.27.29110.0
-- The CXX compiler identification is MSVC 19.27.29110.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/
bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.2911
0/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
**WSL is C:/Windows/System32/wsl.exe**
**command is C:/Windows/System32/wsl.exe;cp;D:/Development/CMakeWSLTest/Input/main.cpp;generated.cpp**
-- Configuring done
-- Generating done
-- Build files have been written to: D:/Development/CMakeWSLTest/BUILD
And the following is the output from cmake build
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Checking Build System
Building Custom Rule D:/Development/CMakeWSLTest/CMakeLists.txt
Building Custom Rule D:/Development/CMakeWSLTest/CMakeLists.txt
Generated generated.cpp
'C:\Windows\System32\wsl.exe' is not recognized as an internal or external command,
operable program or batch file.
For the record, the following works from a DOS shell:
>C:\Windows\System32\wsl.exe cp ../Input/main.cpp generated.cpp

Try giving HINTS to find_program() and point to C:\Windows\Sysnative
Something like this:
if (WIN32)
find_program(WSL wsl HINTS C:/Windows/Sysnative)
message("WSL is ${WSL}")
set (command ${WSL} cp ${source} ${target})
else()
set (command cp ${source} ${target})
endif()
Rationale here: https://superuser.com/a/1528297/2201 but basicly, this could be caused by your cmake buil. find_program() finds executable with absolute path that then should be different when it actually gets called during the build, it should actually point the binary from another location due to inherited build type of parent process of your build.
Maybe..

Related

cmake cannot find an existing directory on mingw64 (msys2)

I am trying to compile a project under MSYS2 and CLANG64 environment.
I have previously compiled dependencies in /usr/local.
$ ls /usr/local/include
boost compat-5.3.c cryptopp lauxlib.h libmongoc-1.0 lua.hpp luajit.h mongocxx yaml-cpp
bsoncxx compat-5.3.h gtest libbson-1.0 lua.h luaconf.h lualib.h tsl
$ ls /usr/local/lib
cmake libboost_filesystem-mt-s-x64.a libbson-static-1.0.a libmongoc-1.0.dll.a
libboost_atomic-mt-s-x64.a libboost_program_options-mt-s-x64.a libbsoncxx-static.a libmongoc-static-1.0.a
libboost_atomic-mt-x64.a libboost_regex-mt-s-x64.a libcryptopp.a libmongocxx-static.a
libboost_chrono-mt-s-x64.a libboost_system-mt-s-x64.a libgtest.a libyaml-cpp.a
libboost_container-mt-s-x64.a libboost_thread-mt-s-x64.a libgtest_main.a pkgconfig
libboost_context-mt-s-x64.a libbson-1.0.dll.a liblua-compat.a
But when I create the project, I explicitly set the location of binaries with interface libraries as I don't want to rely on the find mechanism that has hurt me badly in the past - linking to unintended, old system libraries.
project(test)
cmake_minimum_required( VERSION 3.0 )
add_library( cryptopp STATIC IMPORTED GLOBAL )
set_target_properties( cryptopp PROPERTIES
IMPORTED_LOCATION "/usr/local/lib/libcryptopp.a"
INTERFACE_INCLUDE_DIRECTORIES "/usr/local/include"
INTERFACE_COMPILE_DEFINITIONS "HAVE_CRYPTOPP"
)
add_executable( test test.cpp )
target_link_libraries( test cryptopp )
This works perfect under all Linux distros - Redhat, Ubuntu, etc but fails in MSYS2.
However when I run cmake, I get an error stating that /usr/local/include does not exist.
$ cmake ..
-- Building for: Ninja
-- The C compiler identification is Clang 14.0.4
-- The CXX compiler identification is Clang 14.0.4
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: G:/msys64/clang64/bin/cc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: G:/msys64/clang64/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
CMake Error in CMakeLists.txt:
Imported target "cryptopp" includes non-existent path
"/usr/local/include"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
I just cannot figure out why this is happening. Any clues?
Maybe it's a Windows path issue. Try replacing /usr/local with the output of cygpath -m /usr/local.

MinGW on Windows: cmake arguments to find wxWidgets?

Similar questions already exist but I haven't found an answer that works.
I need to build a wxWidgets project in Windows using MinGW, I would like to use the cmake command from the command line (I installed mingw, cmake and bash using chocolatey)
I would like to avoid compiling wxWidgets so I am using the pre-built binaries MinGW-w64 10.2 (Headers + Dev x64 + Release x64), I unpack them to C:\wxWidgets-3.1.5
I've tried a number of combinations of arguments for cmake but haven't found one that works on the first run, I say first run because I've found one that works on the second:
cmake .. -G "MinGW Makefiles" \
-DwxWidgets_ROOT_DIR=/c/wxWidgets-3.1.5/ \
-DwxWidgets_LIB_DIR=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/
I am not a cmake expert but I imagine that by specifying these arguments in the first run they are cached and in the second run they are used, bypassing the search.
What I would like to know is what arguments I have to give to get them to be found correctly, _CONFIGURATION, _ROOT_DIR, _LIBRARIES, _INCLUDE_DIRS don't seem to have any effect.
↓ edit ↓
CMakelists.txt:
cmake_minimum_required(VERSION 3.18)
project(Test)
set(wxWidgets_USE_LIBS)
find_package(wxWidgets REQUIRED)
if(wxWidgets_FOUND)
include(${wxWidgets_USE_FILE})
add_executable(MyTest WIN32 main.cpp)
target_link_libraries(MyTest ${wxWidgets_LIBRARIES})
else(wxWidgets_FOUND)
message("wxWidgets not found!")
endif(wxWidgets_FOUND)
command line used:
cmake .. -G "MinGW Makefiles" -DwxWidgets_ROOT_DIR=/c/wxWidgets-3.1.5/ -DwxWidgets_LIB_DIR=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/ -DwxWidgets_wxrc_EXECUTABLE=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/wxrc.exe -DCMAKE_BUILD_TYPE=Release -DwxWidgets_LIBRARIES=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/ -DwxWidgets_INCLUDE_DIRS=/c/wxWidgets-3.1.5/include/
first run:
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/ProgramData/chocolatey/bin/g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS core base)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Alex/Documents/Progetti/wx-test/build
wxWidgets not found!
second run:
-- Found wxWidgets: debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxmsw31ud_core.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxmsw31u_core.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31ud.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31u.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31ud_net.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31u_net.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxpngd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxpng.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxtiffd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxtiff.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxjpegd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxjpeg.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxzlibd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxzlib.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxregexud.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxregexu.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxexpatd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxexpat.a;winmm;comctl32;uuid;oleacc;uxtheme;rpcrt4;shlwapi;version;wsock32 (found version "3.1.5") found components: core base net png tiff jpeg zlib regex expat
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Alex/Documents/Progetti/wx-test/build
if I use find_package(wxWidgets REQUIRED):
CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES
wxWidgets_INCLUDE_DIRS)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.21/Modules/FindwxWidgets.cmake:1025 (find_package_handle_standard_args)
CMakeLists.txt:24 (find_package)
Thanks to Process Monitor I noticed that FindwxWidgets.cmake looks for libraries in gcc_dll/ (not gcc2010_x64_dll/), once the directory was renamed cmake -G "MinGW Makefiles" -DwxWidgets_ROOT_DIR=/c/wxWidgets-3.1.5 was enough to find the directory on the first run.

Define compiler and linker in CMAKE

I would like to use CMAKE to compile a special piece of code in C99 with language extensions. Therefore I have to use a "custom" compiler and linker /your/path/to/compiler and /your/path/to/linker. How can I define the compiler and the linker command used by CMAKE?
EDIT:
I tried to define the compiler and linker as suggested by Equod:
set(CMAKE_C_COMPILER /your/path/to/compiler)
set(CMAKE_CUSTOM_LINKER /your/path/to/linker)
set(CMAKE_C_LINK_EXECUTABLE
"<CMAKE_CUSTOM_LINKER> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
But CMAKE is still not taking it:
-- Building for: Visual Studio 15 2017
-- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.16.27040.0
-- The CXX compiler identification is MSVC 19.16.27040.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Programms/VisualStudio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Programms/VisualStudio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/your/path/to/source/build
What I forgot to mention before, I am working on a Windows machine and the executable of th compiler and linker is in the PATH.
EDIT:
Here is my CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(MyProject
VERSION 1.0
DESCRIPTION "This is MyProject"
LANGUAGES C
)
set(CMAKE_C_COMPILER my_compiler)
set(CMAKE_C_LINK_EXECUTABLE my_linker)
configure_file(include/myproject_config.h.in include/myproject_config.h)
set(HEADER_FILES include/main.h include/somefunc.h)
set(SOURCE_FILES src/main.c src/somefunc.c)
add_executable(MyProject ${HEADER_FILES} ${SOURCE_FILES})
target_include_directories(MyProject PUBLIC "${PROJECT_BINARY_DIR}" )
target_include_directories(MyProject PUBLIC "../include" )
P.S.: my_compiler and my_linker are in PATH of cmd and PowerShell.
EDIT:
I installed MinGW now. I have make in my PATH as well. I updated the CMakeLists.txt file above. The make command tries to compile the code now with:
my_compiler #CMakeFiles/MyProject.dir/includes_C.rsp -o CMakeFiles\MyProject.dir\src\main.c.obj -c "C:\mypath\main.c"
But this is not working because I need a command like:
my_compiler -I="../include" "C:\mypath\main.c"
What CMake commands do I need to configure such a behavior?
CMake as default C compiler uses CC environment variables. You can also specify a different compiler and linker setting CMake variables:
Compiler:
set(CMAKE_C_COMPILER /your/path/to/compiler)
Linker:
set(CMAKE_CUSTOM_LINKER /your/path/to/linker)
set(CMAKE_C_LINK_EXECUTABLE
"<CMAKE_CUSTOM_LINKER> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
To better understand why linker settings are done in two steps I'd suggest taking a look at how those variables are managed internally by CMake:
CMake on github

Specify CMake generator unless explicitly passed as command argument by user

In all of the following, I'm using Windows, so WIN32 is always defined in CMake.
I have a CMakeLists.txt file which does its job fine, and I'm using a Preload.CMake file to specify a bunch of stuff, including a certain generator depending on circumstances:
if( WIN32 )
message( "Current generator: ${CMAKE_GENERATOR}" ) # For debugging purposes
if( NOT COMMAND cl OR NOT COMMAND nmake )
set( CMAKE_CXX_COMPILER "g++" )
set( CMAKE_GENERATOR "MinGW Makefiles" CACHE STRING "" FORCE )
set( CMAKE_MAKE_PROGRAM "make" )
message( "MSVC compiler could not be found, attempting with g++ and MinGW makefiles." )
endif( )
endif( )
This allows a Windows user with no Visual Studio to run cmake .. instead of a whole cmake .. -G "MinGW Makefiles".
It works pretty well, here is the output when cmake .. is run from an empty directory (no cache, no nothing):
Current generator:
MSVC compiler could not be found, attempting with g++ and MinGW makefiles.
Windows detected, forcing static libs.
-- The CXX compiler identification is GNU 8.2.0
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/SAYENS/Desktop/picross/build
The problem with this is when I want to specify a generator through the command line. Here is what happens when I run cmake .. -G "MSYS Makefiles" from a MSYS terminal (empty directory, no cache):
Current generator:
MSVC compiler could not be found, attempting with g++ and MinGW makefiles.
CMake Error: Error: generator : MSYS Makefiles
Does not match the generator used previously: MinGW Makefiles
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
(There is no such file as CMakeCache.txt or a CMakeFiles directory, but explicitly specifying a generator in the command line, that is different from the one specified in Preload.CMake, seems to be enough of a source of confusion to print out this message.)
I thought I'd be able to work around the issue by "catching" the value of the -G argument with CMAKE_GENERATOR, but it turns out I can't, as per the first output line Current generator:.
How can I work this out? I tried looking for a way to parse command line arguments, but found none that doesn't involve using a wrapper script, which I'd like to avoid resorting to.
Set the generator name in the environment variable CMAKE_GENERATOR. The documentation says:
Specifies the CMake default generator to use when no generator is
supplied with -G. If the provided value doesn’t name a generator known
by CMake, the internal default is used. Either way the resulting
generator selection is stored in the CMAKE_GENERATOR variable.
Some generators may be additionally configured using the environment
variables:
CMAKE_GENERATOR_PLATFORM
CMAKE_GENERATOR_TOOLSET
CMAKE_GENERATOR_INSTANCE

How to configure ev3dev CMake to use cross compiler

I am attempting to build the ev3dev C++ bindings (see https://github.com/ddemidov/ev3dev-lang-cpp) for my EV3. But CMake isn't using my cross-compiler toolchain. I've successfully installed the code sourcery toolchain, built a simple hello world app, and run it on my brick. That works just fine. The trouble is that CMake uses my host's g++ compiler instead of the toolchain. I'm familiar with linux and cross-compilers, but I'm a total CMake noob. So I suspect CMake is where I'm going wrong.
I've added the following lines into CMakeLists.txt:
set(CMAKE_C_COMPILER "/cygdrive/c/Users/me/MentorGraphics/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi-gcc.exe")
set(CMAKE_CXX_COMPILER "/cygdrive/c/Users/me/MentorGraphics/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi-g++.exe")
Here's the host gcc compiler:
$ gcc --version
gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And the target toolchain gcc compiler:
$ /cygdrive/c/Users/me/MentorGraphics/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/arm-none-linux-gnueabi-gcc.exe --version
arm-none-linux-gnueabi-gcc.exe (Sourcery CodeBench Lite 2014.05-29) 4.8.3 20140320 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The compilers are different versions, so they are really easy to distinguish.
Now here's the terminal session for the cmake build:
$ mkdir build
$ cd build
$ cmake ../ -DEV3DEV_PLATFORM=EV3
-- No build type selected, default to RelWithDebInfo
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
CMake Warning at /usr/share/cmake-3.6.2/Modules/Platform/CYGWIN.cmake:15 (message):
CMake no longer defines WIN32 on Cygwin!
(1) If you are just trying to build this project, ignore this warning or
quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
the CMake cache. If later configuration or build errors occur then this
project may have been written under the assumption that Cygwin is WIN32.
In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.
(2) If you are developing this project, add the line
set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required
at the top of your top-level CMakeLists.txt file or set the minimum
required version of CMake to 2.8.4 or higher. Then teach your project to
build on Cygwin without WIN32.
Call Stack (most recent call first):
/usr/share/cmake-3.6.2/Modules/CMakeSystemSpecificInformation.cmake:36 (include)
CMakeLists.txt:7 (project)
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /cygdrive/c/Users/me/Documents/AppProjects/ev3dev-lang-cpp/build
$
CMake is clearly using the cygwin host gcc/g++ compiler even though I've attempted to configure it to use the toolchain. Where am I going wrong?
EDIT: This is not a duplicate of cmake: problems specifying the compiler (2). I did actually use google, and the cross-compiling instructions on the CMake wiki (https://cmake.org/Wiki/CMake_Cross_Compiling) explicitly dictate using SET(). The problem turned out to be that CMake requires the compiler to be set before PROJECT(). I just moved the SET() lines up above PROJECT() and then CMake found the compiler.