I am trying to generate *.ts files with my CMake, but it does nothing. It even do not show any message. When I am trying directly with lupdate, it is working, so I don't know where the problem might be.
Here my CMakeLists.txt:
cmake_minimum_required(VERSION 3.15 FATAL_ERROR)
project(Band VERSION 1.0.0 LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(Qt5_DIR "C:/QtOpen/5.13.2/msvc2017_64/lib/cmake/Qt5")
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOUIC_SEARCH_PATHS Designer)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_AUTOUIC ON)
set ( SOURCES
Data/Band.cpp
MainWindow.cpp
)
set ( MOC_HEADERS
Data/Band.h
MainWindow.h
)
set ( UIS Designer/band.ui)
set ( RESOURCES application.qrc )
find_package(Qt5 COMPONENTS Core Gui Widgets Xml Network PrintSupport LinguistTools REQUIRED)
qt5_create_translation(QM_FILES MainWindow.cpp english.ts)
add_executable( ${CMAKE_PROJECT_NAME} WIN32 ${SOURCES} ${MOC_HEADERS} ${RESOURCES} ${UIS} ${QM_FILES} icon.rc)
target_compile_definitions(${CMAKE_PROJECT_NAME} PUBLIC DEBUG_MODE)
target_link_libraries(${CMAKE_PROJECT_NAME} Qt5::Widgets Qt5::Gui Qt5::Xml Qt5::PrintSupport)
Can anyone help? I went through all the tutorials, documentation and answers about this topic, but found nothing that could explain why it does not generate .ts file for me. Thanks in advance.
ref: https://doc.qt.io/qt-5/qtlinguist-cmake-qt5-create-translation.html
I think the problem is that just listing ${QM_FILES} as one of the sources in add_executable doesn't force CMake to understand that it needs to generate those files. I guess this is because normally source files are not generated.
You can add the dependency more explicitly via a custom target. After the qt5_create_translation line, add this:
add_custom_target(translations DEPENDS ${QM_FILES})
Then, after the add_executable line, add this:
add_dependencies(${CMAKE_PROJECT_NAME} translations)
Essentially this says there is a target that depends on the generated translation files and that your executable depends on this target, and thus on the generation of the translation files. This should be enough to force qt5_create_translation to be invoked.
Related
How to get CMake to link an executable to an external shared library that is not build within the same CMake project?
Just doing target_link_libraries(GLBall ${CMAKE_BINARY_DIR}/res/mylib.so) gives the error
make[2]: *** No rule to make target `res/mylib.so', needed by `GLBall'. Stop.
make[1]: *** [CMakeFiles/GLBall.dir/all] Error 2
make: *** [all] Error 2
(GLBall is the executable)
after I copied the library into the binary dir bin/res.
I tried using find_library(RESULT mylib.so PATHS ${CMAKE_BINARY_DIR}/res)
Which fails with RESULT-NOTFOUND.
arrowdodger's answer is correct and preferred on many occasions. I would simply like to add an alternative to his answer:
You could add an "imported" library target, instead of a link-directory. Something like:
# Your-external "mylib", add GLOBAL if the imported library is located in directories above the current.
add_library( mylib SHARED IMPORTED )
# You can define two import-locations: one for debug and one for release.
set_target_properties( mylib PROPERTIES IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/res/mylib.so )
And then link as if this library was built by your project:
TARGET_LINK_LIBRARIES(GLBall mylib)
Such an approach would give you a little more flexibility: Take a look at the add_library( IMPORTED) command and the many target-properties related to imported libraries.
I do not know if this will solve your problem with "updated versions of libs".
Set libraries search path first:
link_directories(${CMAKE_BINARY_DIR}/res)
And then just do
target_link_libraries(GLBall mylib)
I assume you want to link to a library called foo, its filename is usually something link foo.dll or libfoo.so.
1. Find the library
You have to find the library. This is a good idea, even if you know the path to your library. CMake will error out if the library vanished or got a new name. This helps to spot error early and to make it clear to the user (may yourself) what causes a problem.
To find a library foo and store the path in FOO_LIB use
find_library(FOO_LIB foo)
CMake will figure out itself how the actual file name is. It checks the usual places like /usr/lib, /usr/lib64 and the paths in PATH.
You already know the location of your library. Add it to the CMAKE_PREFIX_PATH when you call CMake, then CMake will look for your library in the passed paths, too.
Sometimes you need to add hints or path suffixes, see the documentation for details:
https://cmake.org/cmake/help/latest/command/find_library.html
2. Link the library
From 1. you have the full library name in FOO_LIB. You use this to link the library to your target GLBall as in
target_link_libraries(GLBall PRIVATE "${FOO_LIB}")
You should add PRIVATE, PUBLIC, or INTERFACE after the target, cf. the documentation:
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
If you don't add one of these visibility specifiers, it will either behave like PRIVATE or PUBLIC, depending on the CMake version and the policies set.
3. Add includes (This step might be not mandatory.)
If you also want to include header files, use find_path similar to find_library and search for a header file. Then add the include directory with target_include_directories similar to target_link_libraries.
Documentation:
https://cmake.org/cmake/help/latest/command/find_path.html
and
https://cmake.org/cmake/help/latest/command/target_include_directories.html
If available for the external software, you can replace find_library and find_path by find_package.
Let's say you have an executable like:
add_executable(GLBall GLBall.cpp)
If the external library has headers, give the path to its include folder:
target_include_directories(GLBall PUBLIC "/path/to/include")
Add the library directory path:
target_link_directories(GLBall PUBLIC "/path/to/lib/directory")
Finally, link the library name
target_link_libraries(GLBall mylib)
Note that the prefix and extension of the library file are removed:
libmylib.a ➜ mylib
mylib.so ➜ mylib
One more alternative, in the case you are working with the Appstore, need "Entitlements" and as such need to link with an Apple-Framework.
For Entitlements to work (e.g. GameCenter) you need to have a "Link Binary with Libraries"-buildstep and then link with "GameKit.framework". CMake "injects" the libraries on a "low level" into the commandline, hence Xcode doesn't really know about it, and as such you will not get GameKit enabled in the Capabilities screen.
One way to use CMake and have a "Link with Binaries"-buildstep is to generate the xcodeproj with CMake, and then use 'sed' to 'search & replace' and add the GameKit in the way XCode likes it...
The script looks like this (for Xcode 6.3.1).
s#\/\* Begin PBXBuildFile section \*\/#\/\* Begin PBXBuildFile section \*\/\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks \*\/ = {isa = PBXBuildFile; fileRef = 26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/; };#g
s#\/\* Begin PBXFileReference section \*\/#\/\* Begin PBXFileReference section \*\/\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/ = {isa = PBXFileReference; lastKnownFileType = wrapper.framework; name = GameKit.framework; path = System\/Library\/Frameworks\/GameKit.framework; sourceTree = SDKROOT; };#g
s#\/\* End PBXFileReference section \*\/#\/\* End PBXFileReference section \*\/\
\
\/\* Begin PBXFrameworksBuildPhase section \*\/\
26B12A9F1C10543B00A9A2BA \/\* Frameworks \*\/ = {\
isa = PBXFrameworksBuildPhase;\
buildActionMask = 2147483647;\
files = (\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks xxx\*\/,\
);\
runOnlyForDeploymentPostprocessing = 0;\
};\
\/\* End PBXFrameworksBuildPhase section \*\/\
#g
s#\/\* CMake PostBuild Rules \*\/,#\/\* CMake PostBuild Rules \*\/,\
26B12A9F1C10543B00A9A2BA \/\* Frameworks xxx\*\/,#g
s#\/\* Products \*\/,#\/\* Products \*\/,\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/,#g
save this to "gamecenter.sed" and then "apply" it like this ( it changes your xcodeproj! )
sed -i.pbxprojbak -f gamecenter.sed myproject.xcodeproj/project.pbxproj
You might have to change the script-commands to fit your need.
Warning: it's likely to break with different Xcode-version as the project-format could change, the (hardcoded) unique number might not really by unique - and generally the solutions by other people are better - so unless you need to Support the Appstore + Entitlements (and automated builds), don't do this.
This is a CMake bug, see http://cmake.org/Bug/view.php?id=14185 and http://gitlab.kitware.com/cmake/cmake/issues/14185
It has been a long time since the question was posted but I am leaving this one just for reference.
I have a blog post describing step-by-step almost what you (or anyone else) were trying to do.
Please check here: https://michae9.wordpress.com/2022/09/01/shared-lib-to-be-used-by-client-programs-with-cmake/
I have project which has not been divided into libraries, but the source is organized in a directory tree. I do not know how to tell cmake to go down a directory, then add the source in that directory to project defined in the parent directory. I have attempted the following:
in project/source/CMakelists.txt:
set(SOURCE
${CMAKE_CURRENT_SOURCE_DIR}/unitTest/main.cpp
)
add_subdirectory("${PROJECT_SOURCE_DIR}/folder1")
add_executable(UnitTestRNG ${SOURCE} ${HEADERS})
then in project/source/folder1/CMakeLists.txt:
set(SOURCE
${SOURCE}
${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp
)
set(HEADERS
${HEADERS}
${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp
)
using some message() statements, I have found that the the child folder will get the contents of the SOURCE variable, but it's new assignment to that variable will not persist on returning to the parent CMakeLists.txt
Looking for examples and at the cmake tutorial has led me to the conclusion that:
- Source file structures are usually flat within a project
- If code is divided into folders, it is usually is divided into corresponding libraries.
I wonder if there is some "best practice" from which I am deviating by attempting this structure.
Since CMake 3.1 there is a new way to add source from subdirectories: target_sources
Say you have root_dir and root_dir/sub_dir and source files in both. With target_sources you can do this:
In root_dir/CMakeLists.txt define the target
add_library(some_target main.cpp)
add_subdirectory(sub_dir)
In root_dir/sub_dir/CMakeLists.txt add sources:
target_sources(some_target PRIVATE more_cool_stuff.cpp)
some_target will now contain both source files.
It is also possible to use other commands in root_dir/sub_dir/CMakeLists.txt using some_target, for example target_compile_definitions which is quite convenient to add compilation definitions.
I learned about target_sources here, check it out if you want more explanation and examples
Like the second part of arrowdodger's answer says:
in project/source/folder1/CMakeLists.txt:
set(SOURCE
${SOURCE}
${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp
PARENT_SCOPE
)
set(HEADERS
${HEADERS}
${CMAKE_CURRENT_SOURCE_DIR}/file1.hpp
${CMAKE_CURRENT_SOURCE_DIR}/file2.hpp
PARENT_SCOPE
)
Can't you just set all your sources in project/source/CMakelists.txt then?
Anyway, what you need is PARENT_SCOPE or CACHE option on set command.
I was originally following this tutorial: http://www.opengl-tutorial.org/miscellaneous/building-your-own-c-application/
just after about half way down, from where it says "Adding a source file in a project"
I created from this my CMakeLists.txt file as so:
cmake_minimum_required (VERSION 2.6)
project (Cube_Project)
find_package(OpenGL REQUIRED)
add_executable(Cube
main.cpp
)
include_directories(
external/glfw-2.7.6/include/
external/glm-0.9.4.0/
external/glew-1.9.0/include/
.
)
set(ALL_LIBS
${OPENGL_LIBRARY}
GLFW_276
GLEW_190
)
target_link_libraries(Cube
${ALL_LIBS}
)
but when I generate the project, I get this error:
ld: library not found for -lGLFW_276
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any ideas?
I think maybe I'm not using the right names in the set(....) section? My three libs are in a folder called external, which is the top level of the project (i.e. CMakeLists is also here).
I put a zip of the project if anyone wants to take a look at the folder layout of output XCode project structure: http://heather.sh/OpenGL_Project.zip
Thanks,
The library is not in the linker's library search path.
The target_link_libraries command is is very straightforward: It simply passes on all of its arguments to the linker without bothering whether any of those libraries actually exist.
In your case, the GLFW_276 library is missing (and possibly the GLEW_190 as well, since the error occurs before that one is being processed). Make sure the library is actually installed on your system and its filename actually matches the name you use here (eg. libGLFW_276.so).
Once you verify that you have the required file, you need to make sure that the linker is able to find it. If the file is not located in one of the standard directories, use either link_directories to add its location to the search path, or find_library to obtain the full path to the library file, which can then be given to target_link_libraries.
First of all, i'm just a newbie in a CMake magic. And i just want to link libgit2 to my simple C program in CMake way (FindLibgit2.cmake).
As i understand from cmake documentation my CMakeLists.txt should looks like that:
project(libgit2test)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")
# This variables should be setting up externally, i know - i show them just for example
set (LIBGIT2_LIBRARIES "<path to directory with git2.lib and git2.dll")
set (LIBGIT2_INCLUDE_DIR "<path to libgit2/include>")
find_package(Libgit2 REQUIRED)
include_directories(${LIBGIT2_INCLUDE_DIR})
set(LIBS ${LIBS} ${LIBGIT2_LIBRARIES})
target_link_libraries(${PROJECT_NAME} ${LIBS})
In my simple program i just call a couple of simple libgit2 functions and get this:
WARNING: Target "libgit2test" requests linking to directory "<libgit2 build directory>". Targets may link only to libraries. CMake is dropping the item.
I think the problem is here: target_link_libraries(${PROJECT_NAME} {$LIBS})
I try to change it to git2, but than i just get can not open file.
What i'm doing wrong?
P.S. I'm using Visual Studio 2010 compiler, Qt Creator to create CMake project, and successfully build libgit2 with CMake.
Remove
set (LIBGIT2_LIBRARIES "<path to directory with git2.lib and git2.dll")
set (LIBGIT2_INCLUDE_DIR "<path to libgit2/include>")
These variables should be set by find_package(Libgit2 REQUIRED).
I've found the source of problem: variable LIBGIT2_LIBRARIES must point to lib file itself, not the directory of it (debug/release).
However, setting up manually this variables looks like wired. I want to find more "automatic" way to find libgit2 - if one exists.
This may already be answered somewhere, so please point me in the right direction if so - I couldn't find anything that matched my specific problem when googling!
I've got some CppUnit tests that I'm trying to run.
My top-level CMakeLists.txt contains:
include_directories(
${CPPUNIT_INC}
)
link_directories(
${CPPUNIT_LIB}
)
Both of which are set correctly: I print the paths earlier in the CMakeLists.txt file, and they're correct.
In the subfolder, I have;
add_executable(test-lumberjack TestLumberjack.cpp)
target_link_libraries(
test-lumberjack
Lumberjack
CppUnit
${CMAKE_DL_LIBS}
)
INSTALL(TARGETS test-lumberjack DESTINATION ${PROJECT_OUTPUT_TEST_DIR})
ADD_TEST(NAME test-lumberjack COMMAND "${PROJECT_OUTPUT_TEST_DIR}/test-lumberjack")
However, when I run the tests (either by running the file or using ctest -V), I see the usual linker error EDIT: it's not a linker error, see answer below
The library definitely exists, in the path set earlier in the top level CMakeLists.txt.
I'm stumped! I'm assuming there's something key that I'm totally missing, but I haven't a clue what it is. If you'd like more info, let me know and I'll add it.
Cheers.
I'm an idiot: the CppUnit folder wasn't in my library path. Should've realised this when it was crashing at runtime, not during compilation... Doh!