What is the cause for this invalid path issue when trying to run cpp protocol buffer compiler from CMake on Windows 10 and how can I solve it? - cmake

I'm trying to build the aasdk project on a Windows 10 computer. To do this, I am attempting to run the following commands in the root of the git repo directory:
mkdir buildDir
cd buildDir
cmake ..\
cmake --build . --config Release
The last command is obviously the one that's failing. I get the following output when I run that command:
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19041.
-- Found libusb-1.0:
-- - Includes: C:/libusb-master/x64/Release
-- - Libraries: C:/libusb-master/x64/Release/lib/libusb-1.0.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/aasdk-development/buildDir
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(200
,5): warning MSB8062: Custom build for item "C:\aasdk-development\buildDir\CMakeFiles\b2b8e2a3c1aae1e014a7c3c3f8aadde7\AVCha
nnelData.pb.h.rule" specifies invalid path "C:\aasdk-development\buildDir\aasdk_proto\protobuf::protoc" as an additional dep
endency. This may cause incremental build to work incorrectly. [C:\aasdk-development\buildDir\aasdk_proto\aasdk_proto.vcxpro
j]
...
Running cpp protocol buffer compiler on C:/aasdk-development/aasdk_proto/AVChannelData.proto
The filename, directory name, or volume label syntax is incorrect.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(238
,5): error MSB8066: Custom build for 'C:\aasdk-development\buildDir\CMakeFiles\b2b8e2a3c1aae1e014a7c3c3f8aadde7\AVChannelDat
a.pb.h.rule;...' exited
with code 123. [C:\aasdk-development\buildDir\aasdk_proto\aasdk_proto.vcxproj]
Where ... is the same message repetead for each *.proto file inside aasdk_proto directory. From what I can tell, it seems it thinks some paths are invalid. What I can't tell, is which paths and in what way are they invalid.
After the first comment, I decided to check where it gets those paths. Below is the content of the CMakeLists.txt for protobuf, found in the aasdk_proto directory:
include(FindProtobuf)
find_package(Protobuf REQUIRED)
include_directories(${PROTOBUF_INCLUDE_DIR})
file(GLOB_RECURSE proto_files ${CMAKE_CURRENT_SOURCE_DIR}/*.proto)
protobuf_generate_cpp(proto_sources proto_headers ${proto_files})
add_library(aasdk_proto SHARED ${proto_headers} ${proto_sources})
target_link_libraries(aasdk_proto ${PROTOBUF_LIBRARIES})
Of interest is the 5th line which enumerates all the *.proto files in the relevant directory before calling protobuf_generate_cpp, the part which I believe to be causing the errors.
Adding message(STATUS ProtoFiles: ${proto_files}) after line 5 to print the paths yielded correct values, atleast to my eyes:
C:/aasdk-development/aasdk_proto/AbsoluteInputEventData.proto;C:/aasdk-development/aasdk_proto/AbsoluteInputEventData.proto;...
I replaced the forward slash with a backslash just for giggles, since that's how Windows likes them, but that didn't work.

I'm a bit late, but for anyone still having this problem, I ran into a similar issue while building CuraEngine, and found the cause. In my case, I had to set the path to protoc.exe with both variables PROTOC and Protobuf_PROTOC_EXECUTABLE. (I had only set PROTOC and CMake didn't throw any errors.)
I imagine the situation with aasdk must be similar. Some variable (probably PROTOBUF_PROTOC_EXECUTABLE?) that tells the location of protoc.exe must be missing.

Related

CMake with Emscripten and vcpkg can't bind two TOOLCHAIN_FILES

Both vcpkg and Emscripten require to set CMAKE_TOOLCHAIN_FILE to
vcpkg/scripts/buildsystems/vcpkg.cmake and emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake respectively.
How do i do that? or what is the best way to get them both working together?
right now i have a naive attempt:
set(CMAKE_TOOLCHAIN_FILE "/Users/screen-photo-to-text/vcpkg/scripts/buildsystems/vcpkg.cmake" "/Users/emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake")
But it get Could not find toolchain file error and i can't find a way to get this working
To my delight, recently vcpkg received Emscripten support - see PR.
One can install packages like so:
vcpkg install zlib:wasm32-emscripten
Usage is pretty usual standard, for example CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)
project(zpipe CXX)
find_package(ZLIB REQUIRED)
add_executable(zpipe zpipe.cpp)
target_link_libraries(zpipe ZLIB::ZLIB)
The tricky part is still as in question how to combine two toolchains. This invocation works for me:
mkdir build
cd build
emcmake "c:\Program files\CMake\bin\cmake" .. "-G" "Ninja" "-DCMAKE_MAKE_PROGRAM=F:/vcpkg/downloads/tools/ninja/1.10.1-windows/ninja.exe" "-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=%EMSDK%/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake" "-DVCPKG_TARGET_TRIPLET=wasm32-emscripten" "-DCMAKE_TOOLCHAIN_FILE=F:/vcpkg/scripts/buildsystems/vcpkg.cmake" "-DCMAKE_BUILD_TYPE=Release"
emmake ninja
As usually, this needs first Emscripten environment variables set (e.g. with emsdk_env.bat).
Failing to provide this asked second toolchain will result with errors like wasm-ld: error: unknown argument: --out-implib
If for whatever reason (e.g. not absolute path) emcmake can't find the CMake executable, it may result with errors like FileNotFoundError: [WinError 2] The system cannot find the file specified
In case of CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set., as hinted, the CMAKE_MAKE_PROGRAM needs to be set pointing to ninja executable.

How is cmake finding my llvm cmake configuration?

I am wondering how is cmake finding my llvm cmake configuration if I haven't given it any variable telling it where to find it.
I am an LLVM newcomer. I am building a Hello World LLVM pass. I am on Ubuntu 16.04. My version of LLVM is 8.0.0. My version of CMake is 3.5.1.
This is my /CMakeLists.txt file:
cmake_minimum_required(VERSION 3.1)
project(FunctionDebugger)
find_package(LLVM REQUIRED CONFIG)
include_directories(${LLVM_INCLUDE_DIRS})
add_subdirectory(FunctionDebugger)
set(CMAKE_VERBOSE_MAKEFILE on)
This is the FunctionDebugger/CMakeLists.txt file:
add_library(LLVMFunctionDebugger MODULE
FunctionDebugger.cpp
)
set_target_properties(LLVMFunctionDebugger PROPERTIES
COMPILE_FLAGS "-fno-rtti -std=c++11"
)
I configure and compile like this:
mkdir build && cd build
cmake ..
make
It correctly compiles and links a shared library called libLLVMFunctionDebugger.so. What I don't understand is how cmake could find the package requested in:
# <project-root>/CMakeLists.txt
find_package(LLVM REQUIRED CONFIG)
I am not giving it any path nor I have anything defined in the environment but the path to the LLVM binaries.
I read the CMake documentation, but it says that the find_package looks in folders under CMAKE_PREFIX_PATH. I print that variable with message(STATUS ${CMAKE_PREFIX_PATH}) and the output is empty.
Your set-up looks correct and clearly CMake is finding LLVMConfig.cmake script (i.e. the script that find_package consumes to propagate the necessary CMake variables with LLVM 8 set-up).
On the Ubuntu 16.04 machine that I have access to, LLVMConfig.cmake is located in /usr/lib/llvm-8/lib/cmake/llvm/LLVMConfig.cmake, but there's also a symlink in /usr/lib/llvm-8/cmake/. So the natural questions is: does CMake know that it should look there? The answer is yes. In CMake docs you can see that one of the search paths is:
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
You can verify that usr is on the list of prefixes by printing CMAKE_SYSTEM_PREFIX_PATH. On my machine that's set-up to:
/usr/local;/usr;/;/usr;/usr/local
Finally, you can print LLVM_DIR in your CMake script to check which version/installation of LLVM was picked by find_package. The variable will be empty on the first execution of CMake, but then find_package finds LLVM-8, the variable is set and saved in CMakeCache.txt.
Hope this helps.
EDIT
This answer was tested on Ubuntu 16.04 on which LLVM 8 was installed in the default, system-wide location through apt-get. If you install LLVM 8 elsewhere, then there are various ways of pointing CMake to the right location, see the docs for find_package. Editing the PATH variable is one of them:
Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in /bin or /sbin are automatically converted to their parent directories:
PATH
Since cmake 3.17, you can use cmake --debug-find <cmake-options> to ask cmake to output a bunch of debugging information on find_* functions. On my machine, it outputs
Standard system environment variables [CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH].
/home/jiaqi/Documents/LLVM/llvm-project/build
/home/jiaqi/.local
/home/jiaqi/.yarn
/home/jiaqi/anaconda3
/home/jiaqi/anaconda3/condabin
/usr/local
/usr
/
/usr/games
/usr/local/games
/snap
... outputs omitted...
find_package considered the following locations for LLVM's Config module:
/home/jiaqi/Documents/LLVM/Test/build/CMakeFiles/pkgRedirects/LLVMConfig.cmake
/home/jiaqi/Documents/LLVM/Test/build/CMakeFiles/pkgRedirects/llvm-config.cmake
/home/jiaqi/Documents/LLVM/llvm-project/build/LLVMConfig.cmake
/home/jiaqi/Documents/LLVM/llvm-project/build/llvm-config.cmake
/home/jiaqi/Documents/LLVM/llvm-project/build/cmake/LLVMConfig.cmake
/home/jiaqi/Documents/LLVM/llvm-project/build/cmake/llvm-config.cmake
/home/jiaqi/Documents/LLVM/llvm-project/build/lib/cmake/llvm/LLVMConfig.cmake
The file was found at
/home/jiaqi/Documents/LLVM/llvm-project/build/lib/cmake/llvm/LLVMConfig.cmake
So, the cmake is using Config mode here and the file is located at /home/jiaqi/Documents/LLVM/llvm-project/build/lib/cmake/llvm/LLVMConfig.cmake
To figure out how cmake finds the LLVMConfig.cmake, take a look at https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure
For step 5, it says the cmake will search the environment variable $PAT, and note that
Path entries ending in /bin or /sbin are automatically converted to their parent directories.
Since I have put the path to llvm executables in $PATH:
$ echo $PATH
/home/jiaqi/Documents/LLVM/llvm-project/build/bin:/home/jiaqi/.local/bin:/home/jiaqi/.yarn/bin:/home/jiaqi/anaconda3/bin:/home/jiaqi/anaconda3/condabin:/home/jiaqi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
The folder /home/jiaqi/Documents/LLVM/llvm-project/build will be used as prefix. According to https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure, the folder <prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/ will be searched.

CMake generation problem with Visual Studio 2017

Using cmake from command line, I got:
"== Building Windows-Release =="
-- Building for: Visual Studio 15 2017
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_CXX_COMPILER could be found.
Where CMakeError.log contain:
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:
The output was:
1
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 31/12/2018 12:54:05.
Project "C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug\".
Creating directory "Debug\CompilerIdC.tlog\".
InitializeBuildStatus:
Creating "Debug\CompilerIdC.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /nologo /W0 /WX- /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TC /analyze- /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
c1 : fatal error C1083: Cannot open source file: 'CMakeCCompilerId.c': No such file or directory [C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj]
Done Building Project "C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj" (default target) (1) ->
(ClCompile target) ->
c1 : fatal error C1083: Cannot open source file: 'CMakeCCompilerId.c': No such file or directory [C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.43
...
I tried repairing the installation of Visual Studio, and renstalling CMake, but nothing seems to work it. Also looked at similar thread here, but nothing was helpful.
I met the exact same question with you. After a very very long struggle, I finally find the solution for me. I am not sure whether that is the same problem you met, but I still want to write and recode this strange problem.
Firstly, I also reinstall cmake, repair the VS and add many components in it and fixed(brake) many PATH environments, but all of them don't work, and I bet the problem is not because of these problems.
As the two messages:
The C compiler identification is unknown
The CXX compiler identification is unknown
They do not exactly mean the cmake don't detect the VS compiler, it just means that the cmake's use it to build its demo but fail. And from the errorlog, I even can believe your VS has already installed success and work well. The only problem is that the compiler can't open the 'CMakeCCompilerId.c' file.
I don't know whether have your check the .c file is exactly in the project location, but it is in there very well in my computer (otherwise, it means that the cmake failed to create this file, and maybe you need to open it as an administration)
I am very confused about why the compiler can't read that and try to directly open the .vcxproj file in VS and change many settings but still get the same error, like below.
After some try, I move the project to the desktop and reopen it, then it builds success! So as the whole cmake project. I am also be shocked by that.
After some compare and research, I found error reason in me, I am using the git in windows-wsl to clone the project to my windows file system(it has a little risk to break the file permission in wsl), it works well in normal, but as a cmake cross-compilation, I guess it may use some linux-like way to operate files and therefore meet some file permission problem.
So, the final solution to me is using the git in cmd or download the whole project in the browser instead of using the git in wsl. (Truly a little funny-. and may differ with your situation)
Hope these can help you.
The reason for my problem turned out to be that case sensitivity was turned on in the current directory.
Turn off case sensitivity or switch to another directory.

Problems with CPack building multiple packages at once

I'm facing problems using the packaging with CPack and CMake 3.7.2.
I try to build three different packages, MSI (via WIX), IFW, and ZIP.
According to the documentation I set the following variables in my CMakeLists.txt (and a few more which are required):
set(CPACK_WIX_ROOT "C:/Temp/WiX-3.10/binaries")
set(QTIFWDIR "${GLOBAL}/Qt/Tools/QtInstallerFramework/2.0/bin")
set(CPACK_GENERATOR "WIX;IFW;ZIP")
I'm including CPack at the last possible position before any components are defined.
<all variables have been defined before this point>
include(CPack)
include(CPackWIX)
include(CPackIFW)
cpack_add_component(AppBinaries DISPLAY_NAME "MyAppBinaries" DESCRIPTION "My Application Binaries")
cpack_ifw_configure_component(AppBinaries VERSION ${CPACK_PACKAGE_VERSION} SCRIPT "${CMAKE_SOURCE_DIR}/cpack/installscript.qs")
cpack_add_component(AppDocs DISPLAY_NAME "MyAppDocs" DESCRIPTION "My Application Docs")
cpack_add_component(AppData DISPLAY_NAME "MyAppData" DESCRIPTION "My Application Data")
After creating the build dir and running from there
cmake -G "Visual Studio 14 2015 Win64" ..\TestProject
the files CMakeCache.txt, CPackConfig.cmake, CPackSourceConfig.cmake, and CPackProperties.cmake are generated.
When running cpack -C Release to build all three installers at once, the first one (WIX) is built, but the second one (QtIFW) fails with the messages
CPack Error: Cannot find QtIFW compiler "binarycreator": likely it is
not installed, or not in your PATH CPack Error: Cannot initialize the
generator IFW
I inspected the CMakeCache.txt file but found the following entries properly defined:
//QtIFW binarycreator command line client
CPACK_IFW_BINARYCREATOR_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/binarycreator.exe
//QtIFW devtool command line client
CPACK_IFW_DEVTOOL_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/devtool.exe
//QtIFW installer executable base
CPACK_IFW_INSTALLERBASE_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/installerbase.exe
//QtIFW repogen command line client
CPACK_IFW_REPOGEN_EXECUTABLE:FILEPATH=N:/Global/Qt/Tools/QtInstallerFramework/2.0/bin/repogen.exe
//Enable to build 7-Zip source packages
CPACK_SOURCE_7Z:BOOL=ON
//Enable to build ZIP source packages
CPACK_SOURCE_ZIP:BOOL=ON
//Path to a program.
CPACK_WIX_CANDLE_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/candle.exe
//Path to a program.
CPACK_WIX_LIGHT_EXECUTABLE:FILEPATH=C:/Temp/WiX-3.10/binaries/light.exe
But when I checked the CPack\*Config.cmake files none of the entries above are referenced. After running the cmake -G "Visual Studio 14 2015 Win64" ..\TestProject a second time everything is fine; all those entries are referenced in CPack\*Config.cmake files and all three installers can be built.
So I really get stuck at this point.
Any ideas what could be the issue and how to avoid it?
I finally figured out what didn't work as expected. The setting of the QTIFWDIR variable is not saved to the CPack*Config.cmake files, but the CMAKE_WIX_ROOT variable is. Those variables seem to be evaluated at runtime by CPack. Therefore the WIX build run successfully but the IFW build complained about a the missing binarycreator. Adding the variable with its current setting made everything run as expected.
Follow up:
According to the maintainer QTIFWDIR should be rather an environment variable than a CMake variable. And CPACK_WIX_ROOT is considered to be an internal CPack variable. You need to install WIX (and set the WIX environment variable manually, if it hasn't already been done by the installation).

CMake does not compĂ­le Qt5 generate from buildroot

I generate a tarball with Qt5 using Buildroot 2014.05.
When I uncompressed this files to compile my project using CMake I receive the following error message:
CMake Error at <project> /sysroot/usr/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:27 (message):
The imported target "Qt5::Core" references the file
"<project>/host/usr/bin/qmake"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/<project>/sysroot/usr/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"
but not all the files it references.
I'm using the cmake configs under
<project>/sysroot/usr/lib/cmake/
and my CMakeLists.txt
set(CMAKE_PREFIX_PATH <project>/sysroot/usr/lib/cmake/QtWidgets/ )
find_package(Qt5Widgets REQUIRED)
Any suggestion?
Buildroot 2014.05 does not have qmake to install
This part: I generate a tarball with Qt5 using Buildroot does make much sense. What do you mean exactly by this ?
If by this you mean that you tarball'ed the contents of output/host/ (which is the toolchain and all the libraries that you need to build applications for your target), then beware that it is not relocatable. So it has to be installed in the same location as the one it was generated in. So for now, if you want to do this, you should set the BR2_HOST_DIR configuration option to something like /opt/<something>/, and then tarball that up and uncompress it on the other machines where you want to use the toolchain.
It's in our TODO-list to make this relocatable.