I have previously downloaded gdcm-2.4.3 and built it using CMake with the following command.
cmake -G "Visual Studio 10 2010 Win64" ..\gdcm-2.4.3
Which worked fine. I now want to repeat this but now it says it can't find a bunch of header files (sys/time.h, lanfinfo, pthread.h etc - all very Unix-y) and the build fails.
Is there a step I'm missing? I thought I noted everything down last time.
This is probably OK to ignore. It's using the CheckIncludeFiles CMake module to check for the existence of these files and that module outputs a message to show whether it found the file or not.
If there are any actual hard errors while running CMake, there will be output to show this and ultimately the .sln won't be produced.
Related
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.
I've been using QtCreator as my CMake IDE for a long time in Ubuntu. Today I was notified there was an update. So I updated and it looks like I can't compile CMake projects anymore.
This is the error I get when I run CMake from the IDE.
error: The source directory "/tmp/QtCreator-jNrmHx/qtc-cmake-OgPpycUx" does not appear to contain CMakeLists.txt.Specify --help for usage, or press the help button on the CMake GUI.
Any ideas what could be the problem?
I had a similar issue when setting up a new build config with QtC 4.14.
In "CMake Initial parameters", make sure that there is no empty lines, and that each option is one per line. I then deleted the temp source folder re-ran CMake.
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).
I am trying to write a function which uses cmake_parse_arguments to interpret the parameters. This works fine when running cmake in a fresh build directory. However, any time I try to re-run cmake, CMake seems to believe the function does not exist:
CMake Error at CMakeLists.txt:6 (CMAKE_PARSE_ARGUMENTS):
Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
I feel like I'm missing something obvious. I am using CMake 3.3.2 on Arch Linux.
Include CMakeParseArguments with
include(CMakeParseArguments)
Probably it worked the first time because other Find* files included the file already. As the result of the Find* files are cached and not re-run, they no longer included CMakeParseArguments.
I am writing a script and started working with the install command (for copying files) and it is not working. CMake configure/generate does not show any errors (i.e. it does not stop and no warnings/errors show related to this command) and the command does not seem to be working, because I don't see any files being copied.
Since I am new, I am wondering:
How can I tell that install failed (perhaps the source directory was wrong, or the destination directory was wrong)? It appears to be failing silently.
Are there error codes I can check to see what went wrong?
When is install called? When I click configure? Or when the project is built?
I am on Windows.
To the general question, there are a number of ways to get more verbose output from CMake - I just learned a third for gnarly errors:
to debug CMake recipes, I like using the message command and you can even iterate over directories and issue messages*
e.g. message( STATUS "SQLITE3_LIB: ${SQLITE3_LIB} SQLITE3_PATH: ${SQLITE3_PATH}") # prints SQLITE3_LIB and SQLITE3_PATH variables
perform verbose builds to troubleshoot your build itself
run make VERBOSE=1 (with make, ninja -v with ninja, etc.) to help you troubleshoot the process, such as cmake -DYOUR_OPTION="insert values" ~/path/to/files/ && make VERBOSE=1
if you ever find an inscrutable error, I just learned that we can run strace on the failing command - this can be a bit overwhelming, but can help when you have exhausted #1 and #2
I just used strace /usr/bin/cmake -E copy_directory $MY_SOURCE_PATH $MY_DEST_PATH to try to understand why a copy was failing
*I have used DLRdave's answer to a different question to print out the INCLUDE_DIRS:
get_property(dirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY INCLUDE_DIRECTORIES)
foreach(dir ${dirs})
message(STATUS "dir='${dir}'")
endforeach()
When you add an install command to your CMakeLists.txt, you get a new target created called "install".
In order to actually install the chosen files/targets, you need to build this install target. It's not automatically built as part of the "ALL" target.
For example, if you're using Visual Studio, the "INSTALL" target should appear in the "CMakePredefinedTargets" folder of the Solution Explorer. Just selecting this target and building it will cause the solution to be built and the selected items installed.
If any part of the build or install process fails, the notifications should then be apparent.