I'm compiling a software that depends on libpcap,so I yum install libpcap,but when I ./configure it still reports can't find libpcap,so I run yum install libpcap-devel and this time it works.
My question is,what's the difference and what exactly was ./configure looking for when it says libpcap not found?
"lib" contains the things your program needs to run (the ".so" file). "lib-devel" contains the things your program needs to compile (the header files).
Related
I am considering to create a Debian package from an existing library (paho-mqtt-c). The project uses CMake as its build system. After some research I think I need to create two or three different packages:
libpaho-mqtt3 (with library .so files and related stuff)
libpaho-mqtt3-dev (with header files)
also maybe I need a third package with sample files or documentation (called paho-mqtt3?)
I have done some research and it seems there exist at least three different ways how I can create a Debian package when I use CMake as my build system:
Use debmake procedure described in Debian documentation (Chapter 8).
Use cmake-debhelper.
Use dh-cmake
I have looked into all three methods and it seems each has some advantages and disadvantages.
Debmake
As far as I have understood using debmake assumes I have an upstream tarball with the sources and the build system and then I invoke debmake on the extracted tarball. Afterwards I get a lot of templates which I need to manually adjust to fill in the missing gaps. I started doing this but it seems quite complex.
cmake-debhelper
I tried to use it but received lots of errors. The github page has an open issue with no solution so I stopped looking at this. This is also what the paho-mqtt-c build system is currently using, but it does not work due to the issue linked.
dh-cmake
I briefly looked into this and it seems to be the most modern solution and it should be possible to combine this with CPack. However, it seems dh-cmake is only available for Ubuntu 18.04 and 16.04, but I am using Ubuntu 19.10 so I was not able to install dh-cmake on my system.
Have I missed anything in my research? What are the recommended steps to create a Debian package from a software managed with CMake and which documentation is useful to read?
In short, on Ubuntu you need to create at least these files:
debian/
changelog
control
copyright
rules
And then run debuild and it will run cmake install to temporary folder and pack an installable deb package from it.
To quickly create those debian files run dh_make --createorig and press s for source package.
Then you'll need to carefully edit debian files as described in Chapter 4. Required files under the debian directory
of Debian New Maintainers' Guide.
If you need to set cmake properties or make any other configuration then you'll need to adjust override_dh_auto_configure in rules:
#!/usr/bin/make -f
# See debhelper(7) (uncomment to enable)
export DH_VERBOSE = 1
%:
dh $#
override_dh_auto_configure:
dh_auto_configure -- \
-DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
-DIWINFO_SUPPORT=OFF
Here the -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) and -DIWINFO_SUPPORT=OFF will be directly passed to cmake.
You can then upload your package to Ubuntu PPA:
debuild -S -I
dput dput ppa:your-launchpad-user/your-ppa ../*_source.changes
After that PPA build bot will compile and publish your package to PPA and you'll see them on https://launchpad.net/~your-launchpad-user/+archive/ubuntu/your-ppa/+packages
Unfortunately there is a lot of other steps, I just described briefly.
The dh-cmake is needed for more sophisticated things. CPack won't work for you if you want to publish to PPA because its buildbot will anyway run debhelper (short version of debuild) so it needs for the debian folder
or you could use cpack with cmake to generate a deb fairly easy to do but cmake and cpack are poorly documented still they work well
I suggest adding the following to the bottom of CMakeLists.txt
# generate postinst file in ${CMAKE_BINARY_DIR} from template #
CONFIGURE_FILE("${CMAKE_SOURCE_DIR}/contrib/postinst.in" "postinst" #ONLY IMMEDIATE)
# generate a DEB when cpack is run
SET(CPACK_GENERATOR "DEB")
SET(CPACK_PACKAGE_NAME ${CMAKE_PROJECT_NAME})
SET(CPACK_SET_DESTDIR TRUE)
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "grizzlysmit#smit.id.au")
SET(CPACK_PACKAGE_VERSION_MAJOR "0")
SET(CPACK_PACKAGE_VERSION_MINOR "0")
SET(CPACK_PACKAGE_VERSION_PATCH "1")
include(GNUInstallDirs)
SET(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_SOURCE_DIR}/docs/CPack.Description.txt")
SET(CPACK_RESOURCE_FILE_README "${CMAKE_SOURCE_DIR}/docs/README.md")
SET(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/docs/LICENCE")
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libreadline8, libreadline-dev")
SET(CPACK_PACKAGE_VENDOR "Grizzly")
# make postinst run after install #
SET(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CMAKE_BINARY_DIR}/postinst;")
include(CPack)
the postisnt is to run a script after the install see CMAKE/CPACK:I want to the deb executes a bash script after installed, but it doesn't work for more on that.
I am cross-compiling a C library using CMake and a toolchain file. My toolchain file sets CMAKE_SYSROOT to the appropriate value so compilation works with no issues. However, when installing, the library does not install to the directory pointed to by CMAKE_SYSROOT. I can achieve that effect by running make install DESTDIR=xxx though.
I understand that there are two separate concepts here:
The cross-compilation toolchain, which consists of binaries that can be run on my local architecture
The CMAKE_SYSROOT which is the root directory of a target-architecture filesystems, containing header files and libraries, passed to e.g. gcc through the --sysroot flag.
I have two questions:
Is it a good idea to conflate the sysroot where my cross-compilation toolchain lives, with the sysroot where all my cross-compiled libraries will be installed? It feels to me like it should be the same, but am not sure, and to CMake it appears they are distinct concepts. Update: answered in the comments below, these are indeed distinct concepts.
What is the modern CMake way to specify the installation directory when cross-compiling like described above? Update: I believe this should be the same as CMAKE_SYSROOT, and I feel CMake should offer a way to only define this once somewhere.
Thanks!
There is no interference between sysroot and install directory (prefix).
Sysroot is given by CMAKE_SYSROOT variable and denotes prefix for tools used during build process.
Install directory(prefix) is given by CMAKE_INSTALL_PREFIX variable and denotes the path, where the project will be used upon installation. E.g. with install prefix /usr/local the project's executable foo expects to be run as /usr/local/bin/foo.
Note, that with default installation procedure, CMake installs files to the host machine. For install files onto the target machine, this procedure is needed to be adjusted. Parameter DESTDIR=xxx for make install is a way for install files directly to the target machine. Another way is to create a package (e.g. with CPack) on host, and install that package on target machine.
Note, that in the above paragraph it is irrelevant, whether cross-compilation took a place or not: it is possible to build the project on one machine and install it to the other, but similar one, without any cross-compilation.
I'm trying to use CppUTest in Windows, first step is to get it to work and I already have problems. These are the things I've tried:
First Approach
With CMake, using the cmake GUI I can do the configure and generate command and I get something in the output directory, but no binaries and no libraries, just a bunch of cmakefiles. The CMake GUI says everything went OK during the configuration and generation steps, however the libraries (.lib files) are not generated in the output directory... is there something I am missing? I've never used CMake before.
Second approach
With MinGW and msys alone, running cmd in Windows and executing a MinGW shell by typing sh in the Windows terminal, afterwards I execute the following commands:
cd <CppUTest folder>
mount c:\mingw /mingw
./autogen.sh
./configure
make
The build process starts but it fails with a message indicating that pthread.h was not found in MinGW directory. If I install the pthread-win32 package with the MinGW package manager and repeat the same steps as above the build process starts but fails with a message indicating that the structure timespec is defined in time.h and pthread.h.
I've tried to follow this same procedure with CppUTest 3.6 and it works perfectly fine, I get the .lib files, so I guess I will have to continue with this for now.
Does anyone know how to build CppUTest 3.7 (latest release) with MinGW or CMake?
In the end I used Cygwin to compile it, I couldn't find a way to compile it with MinGW properly, I added a dirty trick to make it compile under MinGW (handled the timespec redifinition) but chances are that is going to cause issues.
Just make sure that you use Cygwin aswell to compile your tests, something that I found out after making this question (https://www.youtube.com/watch?v=oVmd0P85D8o).
A quote from the official documentation:
"Specify rules to run at install time."
What exactly is install time?
The problem for me: I am on Linux, software is installed from packages that are just dependencies and data. There is no CMake that can do anything here. So installation time of software is out of scope from CMake. So what exactly do they mean?
Building a CMake project can roughly be divided into three phases:
Configure time. This includes everything that happens while running cmake itself. This phase is concerned with inspecting certain properties of the host system and generating the specific build files for that platform under the selected configuration.
Build time. This includes everything that happens while actually building your project from the files generated by CMake (like, when running cmake --build or make). This is where all of the actual compilation and linking happens, so at the end of the build phase, you have a usable binary.
Install time. This includes everything that happens when running the INSTALL target generated by CMake (like, when running cmake --build --target install or make install). This takes care of copying the binaries that were generated into the build tree to a different directory. Note that the build tree contains a lot of stuff that is no longer needed once the build is completed if you are only interested in running the binary. Examples include all intermediate build artifacts, like the build files generated during the configure phase or the intermediate object files created during the build phase. Furthermore, the install phase might include additional steps to ensure that the binaries produced during the build are portable. For instance, on Linux systems you might want to remove the build directory from the shared library search path in the binary and replace it with a portable equivalent. So the install phase might do more than just copy all the important files to a new directory. It could also include additional steps that change the binaries to make them more portable.
Note that the last phase is optional. If you do not want to support calling make install but prefer another deployment mechanism, you simply don't use the install command in your CMake script and no INSTALL target will be generated.
I'd like to expand the answer, which ComicSansMS gave you, a little bit.
As he mentioned - CMake generates an extra target called install for the make tool (when you use a Makefile-based generator).
It may look weird for you as a package system is used for Linux. However the install target is still useful or even necessary:
When you develop your application you may need to install (move binaries and possibly some include files) to a certain location so some of your projects may see each other. For example, you may develop a library and a set of non-related applications which use it. Then this library must be installed somewhere to be visible. It doesn't mean you need to put it to the /usr directory; you may use your /home.
The process of Linux package preparation requires an install step. For example, the RPM packaging system does three main steps when the rpm package file is being built: the project is configured, then is compiled and linked and finally is being installed to a certain location. All files from this location are being packed to the rpm file.
I have a cmake script that add a "add_custom_command" that generate a program version anytime the program is compiled. That creates a Header File. It works fine...
Now, what I want to do is to have cmake use value from said file during installation and packaging.
Parsing the file is of no worry. What I don't know is how do I ask cmake to parse it just before installing, since it would have been modified during the compilation.
You should check out some of the capabilities of the INSTALL command
INSTALL(CODE "CMAKE_CODE_THAT_PARSES_FILE")
or
INSTALL(SCRIPT CMAKE_Parsing_Script.cmake)
These will be executed at install time.