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).
Related
so I just downloaded wslusing the wsl --install command using PowerShell
now I'm trying to connect it to Clion which works
i cant add images so here is a link to it
but when i'm tying to build the project i get this error
"CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.20 or higher is required. You are running version 3.16.3"
my cmake file:
cmake_minimum_required(VERSION 3.20)
project(ex2 C)
set(CMAKE_C_STANDARD 99)
add_executable(ex2
ex2.c ex2.h
main1.c
main2.c)
i tried updating wsl using wsl --update (in powershell)
The CMake installation inside the WSL is used. Unfortunately currently snap doesn't seem to be available in WSL, but installing the latest CMake version isn't too complicated nonetheless:
(optional) uninstall the old cmake installation in WSL; personally I don't see any benefit in multiple CMake installations, but there may be valid reasons for this. Most likely this will just makes the use of cmake more complex, since you need to remember which cmake version is used.
Download the appropriate cmake version from the cmake website ( https://cmake.org/download/ ). The version to choose is the tar.gz file under binary distributions for the x86_64 target. To get version 3.21.4 (currently the latest release), you can download the file from https://github.com/Kitware/CMake/releases/download/v3.21.4/cmake-3.21.4-linux-x86_64.tar.gz (Identical to the link on the CMake download page).
Unpack the archive from WSL. Navigate to the directory where you want the cmake installation to recide. This will add the cmake-3.21.4-linux-x86_64 directory containing all the files required to work with cmake to the current working directory. Let's assume you want to add the cmake files to the /opt directory. Furthermore let's assume the windows user name to be fabian, C: to be the primary hard drive and the download to be saved to the Downloads directory in the user directory:
cd /opt
tar -xf /mnt/c/Users/fabian/Downloads/cmake-3.21.4-linux-x86_64.tar.gz
(optional) make CMake available without specifying the path; this could be done as described here: https://unix.stackexchange.com/questions/3809/how-can-i-make-a-program-executable-from-everywhere ; don't do this, if an existing cmake installation is already available in the command line assuming you did install cmake to /opt, the cmake binary recides at /opt/cmake-3.21.4-linux-x86_64/bin
You should now be able to use cmake specifying either the full path to the executable (/opt/cmake-3.21.4-linux-x86_64/bin/cmake assuming you used the /opt directory) or directly via a command after opening the WLS commandline again (provided you followed step 4).
Now the only thing left to do should be telling CLion about the location of the cmake executable. Note that I haven't tested this, since I don't use this IDE. It's working fine using Visual Studio Code though...
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 am trying to add aws-sdk-cpp as a submodule in my Qt application using Qt Creator and CMake. I want it to build for any platform without doing the building and installing on the command line as described here.
My project structure and CMakeLists.txt files looks like this:
I have successfully built the entire aws-sdk-cpp using MSVC2019 in debug mode using Qt Creator. My projects build folder is now 15 GB containing all the built libraries. The current issue I'm now facing is this error:
CMake Error at app/CMakeLists.txt:23 (find_package):
By not providing "FindAWSSDK.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "AWSSDK", but
CMake did not find one.
Could not find a package configuration file provided by "AWSSDK" with any
of the following names:
AWSSDKConfig.cmake
awssdk-config.cmake
Add the installation prefix of "AWSSDK" to CMAKE_PREFIX_PATH or set
"AWSSDK_DIR" to a directory containing one of the above files. If "AWSSDK"
provides a separate development package or SDK, be sure it has been
installed.
I think what is missing is the make install step described here and to set the path to AWSSDK_DIR.
I'm very new to CMake and I have not found any way to perform the make install step in the CMakeLists.txt file and then be able to set the AWSSDK_DIR which points to the AWSSDKConfig.cmake or awssdk-config.cmake file missing.
I'm also not sure which CMakeLists.txt file this should be written or if there is an entire other way to do this? Currently I'm stuck getting nowhere..
I'm using CMake to generate my makefiles. My deployable target is an RPM, and that's all working well. Per the file system guidelines, my RPM installs to
/opt/mytool
/bin - executables
/lib64 - libraries
/etc/opt/mytool - configuration files
The RPM gets built by CPack using make package
During development testing, I don't want to install an RPM. It requires elevated privileges and limits any given machine to one (developer) version at a time. Before I got all the RPM stuff working, I was able to "make install" and create a simple install tree like this:
install
/opt/mytool
bin
lib64
However, the introduction of the config files to a different location has gummed up the works. I'd like this to be extended to include
install
/etc/opt/mytool
but I can live without it. Unfortunately, when I try make install I get this error:
Install the project...
-- Install configuration: "Debug"
CMake Error at cmake_install.cmake:49 (file):
file cannot create directory: /etc/opt/mytool. Maybe need administrative
privileges.
The offending part of the CMakeLists.txt file is
install(FILES ${PROJECT_SOURCE_DIR}/../Config/mytool.cfg
DESTINATION /etc/opt/mytool
)
I've looked at CMake rpm installing a file in /etc/init.d, but my RPM builds just fine (and I'm using CMake 3)
What is the difference between make install and make package (I can infer that the latter is running CPack, and it works just fine)? How can I create a development install tree
The difference between the two build targets is that package creates an RPM file in your case while install copies the resources given to the install() command to the location provided to the DESTINATION parameter:
DESTINATION
Specify the directory on disk to which a file will be
installed. If a full path (with a leading slash or drive letter) is
given it is used directly. If a relative path is given it is
interpreted relative to the value of the CMAKE_INSTALL_PREFIX
variable. The prefix can be relocated at install time using the
DESTDIR mechanism explained in the CMAKE_INSTALL_PREFIX variable
documentation.
You specified to copy files to /etc/opt/mytool for which you obviously have no write permissions and encounter the cited error.
You have two options to resolve this, the second one is clearly preferred, because it allows every developer to provide their own, system-local setting, where to temporarily install dev files:
set a DESTINATION path for which you have write permissions
set a relative path and call cmake with an additional argument to specify where your development install tree is:
cmake -H<source path> -B<build path> -DCMAKE_INSTALL_PREFIX=<install path>
I used cmake 3.12.0. There are exists one cmake project that creates one console application. I add the ability of package generation to that cmake project:
# ... above cmake code for one console application creation
# below code that I add:
# pack
set (A_PACK_DESCRIPTION_SUMMARY "${PROJECT_NAME} - CMake Assistant Solution")
set (A_INSTALL_PREFIX Consolas)
set(CPACK_WIX_PRODUCT_GUID "F9AAAAE2-D6AF-4EA4-BF46-B3E265400CC8")
set(CPACK_WIX_UPGRADE_GUID "F9AAAAE2-D6AF-4EA4-BF46-B3E265400CC7")
set(CPACK_GENERATOR "WIX")
include(CPack)
With other generators (NSIS, 7Z, ZIP, DEB) all works fine but with WIX appears followed error:
...path\files.wxs(11) : error LGHT0091 : Duplicate symbol 'Component:CM_C_EMPTY_INSTALL_ROOT' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.
Why it happens and how to fix it?
This appears to be caused by this bug
Basically you use add_subdirectory(xxx EXCLUDE_FROM_ALL) where the subdirectory has a install(... COMPONENT ...) call. The installed files are excluded from the subdirectory, but still creates COMPONENTs, which are now empty and break wix.
As a workaround, you can add:
set(CPACK_COMPONENTS_ALL Unspecified)
in CMakeLists.txt to exclude all the empty components.
If it helps any, I had this problem and found that I had INSTALL commands that specified only Release Configurations but then tried to build the package using the Debug build configuration. By just switching to building the package specifying the Release configuration all went as expected (Wasted most of an afternoon before I figured this out!)