I need to add libavahi-client3 to cmake dependency of my project. Also need to check libavahi-client3 and libavahi-common3 existence. Problems only with current library(avahi)
Trying to do these things:
find_package(libavahi-common3)
if(NOT libavahi-common3_FOUND)
message(ERROR " libavahi-common3 is not found")
endif(NOT libavahi-common3_FOUND)
OR this variant:
find_library(AVAHI_COMMON_LIBRARY NAMES libavahi-common3)
if(NOT AVAHI_COMMON_LIBRARY_FOUND)
message(ERROR " libavahi-common3 is not found")
endif(NOT AVAHI_COMMON_LIBRARY_FOUND)
Both do not work, i searched for something like findAvahi.cmake, but found nothing. So should i write my own search module or there is another better option?
There is currently no find script for avahi shipping with CMake, which is why your first example does not work. It is important to understand that find_package simply runs an external find script, it does not perform any searching by itself.
Your second example is broken, mixing idioms from find_library and find_package. Please read up on the documentation of find_library and find_path which will help you find the required libraries and include paths.
If you want you can turn that into a find script later (look at the scripts in CMake's module directory to get an idea what such a script should look like), which will allow you to use the more compact find_package for locating the library again. Note that writing a find script that works reasonably well on different platforms is a complex task that will require some research effort to get it right.
Related
Everything is in the title, but for more context informations:
I am creating a library, where all components are independent (it's only because it's easier to manage 1 git repo, really).
In that library's root folder, I have 1 sub-folder for each part of the library's components, with exactly 3 "interesting folders" (src,tests,include/components_name). I have hardcoded those folders in a foreach loop so that all actions will be done for all modules by default.
The problem seems to be that, one of the modules is named "option_parser" which is, indeed, relatively generic, and also seems to be "reserved" by cmake, and same for everything derived from it. I've tried "option_parser_test", "option_parser_tests", and other random names based on "option_parser_" root.
So, here is my question: where I can learn how to avoid names that cmake reserves?
And how can I affect them anyway to my binaries (because, I feel like it's stupid to change a project's name because of a build system. Might be a strong enough reason to switch it.)
It's really quite simple. Use these three commands to see all reserved words:
cmake --help-command-list
cmake --help-variable-list
cmake --help-property-list
The answer of Cinder Biscuits above should probably already help you.
Additionally, you should probably read CMake's own documentation regarding the CMake language and in particular the note in the "Variables" section:
Note: CMake reserves identifiers that:
begin with CMAKE_ (upper-, lower-, or mixed-case), or
begin with _CMAKE_ (upper-, lower-, or mixed-case), or
begin with _ followed by the name of any CMake Command.
I need to link with a third-party pre-built shared library. On Windows, that means linking with Third_party.lib, and on Linux/Android, that means linking with libThird_party.so. So in the interest of cross-platformness, I tried to write that as:
${CMAKE_IMPORT_LIBRARY_PREFIX}Third_party${CMAKE_IMPORT_LIBRARY_SUFFIX}
Which works fine on Windows, but on Linux/Android, these variables are blank. I get that Linux/Android doesn't have import libraries, but nonetheless these variables being blank is actually a big nuisance. And changing the variables to CMAKE_SHARED_LIBRARY_... doesn't work either, because even though Linux/Android would then look for lib/.so like I want, Windows will look for .dll, which I don't want.
It seems like I can fix this by populating the import library variables (only on Linux) with values from the shared library variables. But... is this really the best way? I can't possibly be the first person to bump into this.
Usually you let CMake and its helpers do that job of figuring the right name out. Quite possibly, for your third party library, there's already a Find<Library>.cmake script out there.
If there isn't: Here's something taken from FindUSB.cmake from GNU Radio
if(NOT LIBUSB_FOUND)
pkg_check_modules (LIBUSB_PKG libusb-1.0)
find_path(LIBUSB_INCLUDE_DIR NAMES libusb.h
PATHS
${LIBUSB_PKG_INCLUDE_DIRS}
/usr/include/libusb-1.0
/usr/include
/usr/local/include
)
find_library(LIBUSB_LIBRARIES NAMES usb-1.0 usb
PATHS
${LIBUSB_PKG_LIBRARY_DIRS}
/usr/lib
/usr/local/lib
)
if(LIBUSB_INCLUDE_DIR AND LIBUSB_LIBRARIES)
set(LIBUSB_FOUND TRUE CACHE INTERNAL "libusb-1.0 found")
message(STATUS "Found libusb-1.0: ${LIBUSB_INCLUDE_DIR}, ${LIBUSB_LIBRARIES}")
else(LIBUSB_INCLUDE_DIR AND LIBUSB_LIBRARIES)
set(LIBUSB_FOUND FALSE CACHE INTERNAL "libusb-1.0 found")
message(STATUS "libusb-1.0 not found.")
endif(LIBUSB_INCLUDE_DIR AND LIBUSB_LIBRARIES)
mark_as_advanced(LIBUSB_INCLUDE_DIR LIBUSB_LIBRARIES)
endif(NOT LIBUSB_FOUND)
Notice the pkg_check_modules directive and the find_library directive that take care of giving you the right things without you hand-appending suffixes etc.
You'll probably want to add the path you expect your .dll to be to the PATHS arguments of find_path and find_library (those are pointers for CMake to know where to look).
I wrote the following CMakeLists.txt in order to build a tester using CxxTest (it's almost the standard example provided by FindCxxTest):
cmake_minimum_required(VERSION 2.8)
project(tester)
set(CMAKE_INCLUDE_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
find_package(CxxTest REQUIRED)
if(CXXTEST_FOUND)
include_directories(${CXXTEST_INCLUDE_DIR})
enable_testing()
CXXTEST_ADD_TEST(tester_executable runner.cpp
${CMAKE_CURRENT_SOURCE_DIR}/myTestsuite.h)
endif()
The problem is that CxxTest is not found although I have the folder cxxtest and the file cxxtest/TestSuite.h inside the directory where CMakeLists.txt exists.
I already looked into the source code of FindCxxTest.cmake to see how far it gets, but it doesn't even find the path CXXTEST_INCLUDE_DIR.
Do I have to set another search path or something? I'm testing on Windows.
find_path does not search the current list directory. That is, just because a relative path is reachable from the current CMakeLists.txt, does not mean that it will be found. You can find a complete description of the search order in the manual.
A quick and dirty solution is to add the respective directory to your CMAKE_PREFIX_PATH:
set(CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR})
find_package(CxxTest)
More fine grained control is available via the CMAKE_SYSTEM_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH and CMAKE_PROGRAM_PATH variables. Also, some find scripts provide means of injecting search hints without having to pollute the global variables (although FindCxxTest does not seem to offer this).
Another option is, if you anyway include the CxxTest sources at a fixed place in your source tree, to not use the the find script at all, but hardcode the paths instead.
This may feel like a dirty solution at first, but if you can really rely on the sources always being there, it's actually the cleanest and most robust way to solve this. Find scripts really only make sense when you can not say where exactly on the system the files are located.
When setting link libraries in the following manner
target_link_libraries (SOME_TARGET -L/somedir -lfoo)
cmake doesn't handle RPATHs. Is using '-L' and '-l' not best practice, or actually plain wrong? When creating my own Find*.cmake I usually use find_library() but the find script I got doesn't do this and resorts to the above form using '-L' and '-l'.
The documentation doesn't really explain how RPATHs are gathered, also the documentation isn't really clear how it handles "-l" and "-L" the only pointer you get is
"Item names starting with -, but not -l or -framework, are treated as
linker flags"
Specifying toolchain-dependent flags like -l and -L is generally not recommended, as it breaks portability and might have different effects than you expect.
The correct way to set the linker path would be the link_directories command.
The idiomatic solution in CMake is to use find_library for locating the library and then pass the full path to the linker, so you do not need to worry about link directories at all.
Now, the RPATH is a different beast, as it also determines where dynamic libraries can be located at runtime. Usually, the default settings work reasonably fine here. If you ever find yourself in the unfortunate situation where it does not, there is a number of target properties and CMake variables influencing this:
There are a few properties used to specify RPATH rules. INSTALL_RPATH
is a semicolon-separated list specifying the rpath to use in installed
targets (for platforms that support it). INSTALL_RPATH_USE_LINK_PATH
is a boolean that if set to true will append directories in the linker
search path and outside the project to the INSTALL_RPATH.
SKIP_BUILD_RPATH is a boolean specifying whether to skip automatic
generation of an rpath allowing the target to run from the build tree.
BUILD_WITH_INSTALL_RPATH is a boolean specifying whether to link the
target in the build tree with the INSTALL_RPATH. This takes precedence
over SKIP_BUILD_RPATH and avoids the need for relinking before
installation. INSTALL_NAME_DIR is a string specifying the directory
portion of the “install_name” field of shared libraries on Mac OSX to
use in the installed targets. When the target is created the values of
the variables CMAKE_INSTALL_RPATH, CMAKE_INSTALL_RPATH_USE_LINK_PATH,
CMAKE_SKIP_BUILD_RPATH, CMAKE_BUILD_WITH_INSTALL_RPATH, and
CMAKE_INSTALL_NAME_DIR are used to initialize these properties.
(From the set_target_properties docs)
Also, you might want to have a look at the CMake Wiki page for RPATH handling.
The whole RPATH business is unfortunately rather complex and a thorough explanation would require far more space than is appropriate for a StackOverflow answer, but I hope this is enough to get you started.
Basically, You're using target_link_libraries() wrong. According to documentation, You should provide target, libraries and maybe some CMake specific linkage flags.
For example something like that:
target_link_libraries(my_build_target somedir/foo.so)
If You're using Your own crafted Find*.cmake solutions, it's usualy being done like this:
find_library(foo)
//build main target somewhere here
//now link it:
target_link_libraries(my_build_target ${FOO_LIBRARIES})
NOTE: I assume Your crafted Find*.cmake files follows these guidelines and fills CMake variables like SOMELIB_LIBRARIES, and/or SOMELIB_INCLUDE_DIRS, etc.
NOTE2: for my personal opinion, target_link_directories() is pain in a butt and You should avoid using it if not really needed. It's difficult to maintain and uses paths relative to current source directory.
I'm trying to find the avformat library for my project using CMake. My first option was to use a FIND_PACKAGE(...) but I couldn't find any CMake Module for it in $CMAKE_ROOT/Modules. Now I'm trying to find it using FIND_LIBRARY(...).
The library is in /usr/lib/libavformat.so.52.
This is my CMake code for finding it:
find_library(AVFORMAT_LIBRARY avformat PATHS /usr/lib DOC "avformat library")
if(NOT AVFORMAT_LIBRARY)
message(FATAL_ERROR "Library avformat required, but not found!")
endif(NOT AVFORMAT_LIBRARY)
However, I can't find it. Why do you think that is?
I could type the specific library name (i.e. libavformat.so.52), but that would tie the code to that specific version, which I wouldn't want.
EDIT: I just tried typing the exact library name libavformat.so.52 and that didn't work either. :S
What are your suggestions?
Thank you.
So I found what the problem was.
If you do a search for 'avformat' in aptitude/synaptic you get a couple results but no libavformat-dev. So I thought there was none! However, if you search for 'libavformat' then the library appears! I swear I thought that aptitude/synaptic did a regular expression search, not just for the beginning. -.-
Now it all works! :D