I am on Cygwin and I would like to call a compiler installed on Windows. I have an issue with the paths format.
With this very simple CMakeLists.txt:
cmake_minimum_required(VERSION 3.6)
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR Cortex-M4)
set(CMAKE_C_COMPILER iccarm.exe)
set(CMAKE_CXX_COMPILER iccarm.exe)
set(CMAKE_ASM_COMPILER iasmarm.exe)
project("test" C)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
if(NOT EXISTS main.c)
file(WRITE main.c "int main(void){return 0;}\n")
endif()
add_executable(
test
main.c
)
I get an issue when CMake checks for the compiler:
-- The C compiler identification is IAR
-- Check for working C compiler: /cygdrive/c/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/arm/bin/iccarm.exe
-- Check for working C compiler: /cygdrive/c/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/arm/bin/iccarm.exe -- broken
CMake Error at /usr/share/cmake-3.6.2/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "/cygdrive/c/Program Files (x86)/IAR Systems/Embedded
Workbench 8.0/arm/bin/iccarm.exe" is not able to compile a simple test
program.
It fails with the following output:
Change Dir: /cygdrive/c/Users/nobody/home/sandbox/cmakeiar/CMakeFiles/CMakeTmp
It is because CMake doesn't know, or perhaps it should know, that iccarm.exe is a Windows program that is expecting windows paths.
Is there a solution to give CMake this information?
I imaging something like:
if(PLATFORM_IS_CYGWIN)
set(CMAKE_IS_WINDOWS_EXECUTABLE iccarm.exe)
endif()
Turning my comments into an answer
Please be aware that Cygwin's CMake would give /cygdrive prefixes, but Windows installed CMake version won't.
I've run a test with your CMakeLists.txt, the IAR ARM compilers in my PATH environment and could successfully run from the Cygwin bash shell:
$ /cygdrive/c/Program\ Files/CMake/bin/cmake -G "Unix Makefiles" ..
-- The C compiler identification is IAR
-- Check for working C compiler: C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/arm/bin/iccarm.exe
-- Check for working C compiler: C:/Program Files (x86)/IAR Systems/Embedded Workbench 8.0/arm/bin/iccarm.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: ...
If I do just call cmake .. (the Cygwin version) I get the same errors you got.
Related
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.
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.
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..
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
For demonstration, I use the 3-line CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
find_package( BLAS REQUIRED )
message( STATUS BLAS found: ${BLAS_LIBRARIES} )
I have cblas, ATLAS and OpenBLAS including developer packages installed on a Debian Linux system, plus CMake 2.8.9. When I call
cmake . -DBLA_VENDOR=ATLAS -DCMAKE_PREFIX_PATH=/usr/lib/atlas-base
the ATLAS library nicely appears found:
-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for dgemm_
-- Looking for dgemm_ - found
-- A library with BLAS API found.
-- BLASfound:/usr/lib/atlas-base/libf77blas.so/usr/lib/atlas-base/libatlas.so
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp
Similarly, just
cmake .
will find /usr/lib/libblas.so for me. (I do not forget to remove the cache files before the second call.)
When I look into /usr/share/cmake-2.8/Modules/FindBLAS.cmake, I read as the permitted values of BLA_VENDOR:
## Goto,ATLAS PhiPACK,CXML,DXML,SunPerf,SCSL,SGIMATH,IBMESSL,Intel10_32 (intel mkl v10 32 bit),Intel10_64lp (intel mkl v10 64 bit,lp thread model, lp64 model),
## Intel10_64lp_seq (intel mkl v10 64 bit,sequential code, lp64 model),
## Intel( older versions of mkl 32 and 64 bit), ACML,ACML_MP,ACML_GPU,Apple, NAS, Generic
That is, OpenBLAS is not listed. And a few random trials like
cmake . -DBLA_VENDOR=open -DCMAKE_PREFIX_PATH=/usr/lib/openblas-base
do not work either. Do I have to write my own FindBLAS in order to link to OpenBLAS with CMake?
CMake supports finding OpenBLAS using FindBLAS since CMake 3.6.0, as this commit finally made it into the release.
NB: OpenBLAS can also be used to substitute LAPACK, for which you should use the FindLAPACK command, that is also available since 3.6.0.
The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS.
(See: https://blog.kitware.com/cmake-3-6-0-rc3-is-now-ready/)
I think you have to write your own CMake module for that.
You can check there and there maybe for inspirations
According to caffe, you can use it this way,below is my project structure:
FindOpenBLAS.cmake contents as below:
SET(Open_BLAS_INCLUDE_SEARCH_PATHS
/usr/include
/usr/include/openblas
/usr/include/openblas-base
/usr/local/include
/usr/local/include/openblas
/usr/local/include/openblas-base
/opt/OpenBLAS/include
$ENV{OpenBLAS_HOME}
$ENV{OpenBLAS_HOME}/include
)
SET(Open_BLAS_LIB_SEARCH_PATHS
/lib/
/lib/openblas-base
/lib64/
/usr/lib
/usr/lib/openblas-base
/usr/lib64
/usr/local/lib
/usr/local/lib64
/opt/OpenBLAS/lib
$ENV{OpenBLAS}cd
$ENV{OpenBLAS}/lib
$ENV{OpenBLAS_HOME}
$ENV{OpenBLAS_HOME}/lib
)
FIND_PATH(OpenBLAS_INCLUDE_DIR NAMES
cblas.h PATHS ${Open_BLAS_INCLUDE_SEARCH_PATHS}
)
FIND_LIBRARY(OpenBLAS_LIB NAMES
openblas PATHS ${Open_BLAS_LIB_SEARCH_PATHS}
)
message("OpenBLAS_INCLUDE_DIR: ${OpenBLAS_INCLUDE_DIR}, OpenBLAS_LIB: ${OpenBLAS_LIB}")
when use cmake it outputs :
The main CMakeLists.txt use the above FindOpenBLAS.cmake to find blas:
cmake_minimum_required(VERSION 3.5)
project(my_caffe)
set(CMAKE_CXX_STANDARD 11)
#dependence lib
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)
find_package(OpenBLAS REQUIRED)
set(SOURCE_FILES main.cpp)
add_executable(my_caffe_test ${SOURCE_FILES})
# link blas
target_link_libraries(my_caffe_test
${OpenBLAS_LIB}
)