Let be a library A that I compile with CMake. I also want to distribute it via a package (e.g. RPM).
Where should my package install the files AConfig.cmake and AConfigVersion.cmake ?
In /usr/share/cmake/Modules on Linux ?
You should find what you need here:
http://www.cmake.org/Wiki/CMake/Tutorials/Packaging
With the relevant portion of the text:
Consider a project "Foo" that installs the following files:
<prefix>/include/foo-1.2/foo.h
<prefix>/lib/foo-1.2/libfoo.a
It may also provide a CMake package configuration file
<prefix>/lib/foo-1.2/foo-config.cmake
The config files need the be in your install tree. Only the FindXXX.cmake file should go in the modules directory.
Related
Say I have the following basic CMakeLists.txt file.
target_include_directories( addnum
PUBLIC
"${CMAKE_CURRENT_SOURCE_DIR}/include"
)
add_executable(addnumapp src/main.cpp)
target_link_libraries(addnumapp addnum)
SET(CPACK_GENERATOR "DEB")
set(CPACK_DEBIAN_PACKAGE_DEPENDS "g++ (>= 7), libffi-dev, libncurses5-dev, libsqlite3-dev, mcpp, zlib1g-dev")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Some person")
INCLUDE(CPack)
To create a "deb" package, I create a build directory and run the following command to build my project:
cmake -S . -B ./build
I then run the cpack command from within the build directory and a ".deb" package is generated. This is great to generate a single ".deb" package; however, I would like to generate multiple packages using cmake and cpack and I'm unsure what the best way to go about this is.
For example, how do I generate ".deb" packages for all the supported Debian architectures?
From my research, I'm aware of the following command, which allows you to specify an architecture:
set(CPACK_DEBIAN_PACKAGE_ARCHITECTURE, "i386")
However, this only works if you're generating a single Debian package through the method I've outlined above. How does one generate multiple Debian packages for all the different architectures?
My second question is about generating multiple packages for different Operating Systems. For example, the above CMakeLists.txt file just generates a Debian package; however, I would also like to generate packages for MacOS and Windows.
From my research, I'm aware that the following edits to my CMakeLists.txt file should theoretically be the minimal changes required for me to generate a ".dmg" package for MacOS in addition to the Debian package I also want generated.
...
SET(CPACK_GENERATOR "DEB;DragNDrop") # modification here
set(CPACK_DEBIAN_PACKAGE_DEPENDS "g++ (>= 7), libffi-dev, libncurses5-dev, libsqlite3-dev, mcpp, zlib1g-dev")
SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE i386)
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Some person") #required
INCLUDE(CPack)
INCLUDE(CPackDMG) # addition here
However, when I run cmake -S . -B ./build on this modified CMakeLists.txt file (from an Ubuntu OS), I get the following error:
CMake Error at CMakeLists.txt:28 (INCLUDE): INCLUDE could not find
requested file:
CPackDMG
-- Configuring incomplete, errors occurred!
Is this error because I'm trying to generate a MacOS "dmg" package from Ubuntu or is it because I'm missing some cpack dependency?
Further, is this the best way to generate different packages for different platforms?
To summarise, my two questions are (1) how to generate multiple packages for different architectures and (2) how to generate multiple packages for different platforms? (Please bear in mind that I'm very new to C++, CMake and CPack.)
(1) how to generate multiple packages for different architectures
Just use different build environments (hardware, docker containers, virtual machines, ...) or use cross-compilation and toolchain files.
(2) how to generate multiple packages for different platforms?
CPackDMG is an internal CPack module. You don't need to include it. Your CMakeLists.txt should use only CPack and set desired variables before. Set CPACK_GENERATOR to the list of package types you want and the generator-specific variables. However, some generators use external tools -- e.g., to build RPM package your environment requires working rmbuild tool... meaning that it'll be hard to build RPM package within a Debian distro %) In other words, you most likely fail to build DMG when building your package in Linux/Windows :)
I am having a similar issue to this problem.
I want to download Meson for Windows and used the following command:
pip3 install meson
This installs in my site-packages folder, specifically c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.8_qbz5n2kfra8p0\localcache\local-packages\python38\site-packages\mesonbuild
However, running meson or python3 meson.py results in an error:
'meson' is not recognized as an internal or external command, operable
program or batch file.
When looking at the mesonbuild directory within site-packages, I seem to be missing the meson or meson.py file. Has anybody ever come across this issue before?
After opening up Visual Studio, and looking at the installed Python packages in my environment, I noticed this interesting information window above the list of my Python packages:
Due to new security restrictions, installing from the internet may not
work on this version of Python.
After seeing this, I decided to install Meson through the website's MSI installer. Indeed, after trying to download the installer, Windows threw up all kinds of security warnings and "are you sure you want to do this" notifications before I convinced Windows that I really did want to install Meson.
I just wanted to share this with anybody that might have the same issues. The MSI installer worked for my needs.
Try the following :
python3 -m mesonbuild.mesonmain build
Meson pip package contains meson and mesonbuild modules. The meson module serves as Python entry point, which, during an initial execution of setup.py, associates mesonbuild.mesonmain:main with command line name 'meson'. (Explain Python entry points?). To invoke meson via python3 use python3 -m mesonbuild.mesonmain build, which writes build config into 'build' directory (provided that there is meson.build file in the current directory.) There is no such file 'meson.py' in mesonbuild module and meson module does not contain any Python code.
After I install the package transformer by pip install transformer, I find it under three locations.
/home/jinggu/anaconda3/bin/transformers
/home/jinggu/anaconda3/lib/python3.7/site-packages/transformers-2.1.1.dist-info/*
/home/jinggu/anaconda3/lib/python3.7/site-packages/transformers/*
What is the difference between these three?
The two in site-packages are for the metadata about the package (transformers-2.1.1.dist-info/) and the actual source code (transformers/). The file in the bin/ folder is called an entry point and represents a commandline interface provided by the package. In this case, you can see this defined in the setup.py file and that it points to running the main() function.
The anaconda3/bin folder contains executables installed w/ the package. If packages would like to provide a command line interface they will come with binaries to be executed from the command line. Not sure what transformers is, but if you navigate to anaconda3/bin/ you should be able to ./transformers -flags or cla's.
The python3.7/site-packages/ folders contain the python source code that can be imported to be used in your projects. This is generally how anaconda packages are used - and how you use the packaged libraries through conda's environment.
In your case, the transformers package came with binaries as well as the source code (to be imported for use in your projects).
I am building binaries for our custom board(iMX7) using Yocto-morty. I need some libraries such as UTF-32.so, UTF-16.so, UTF-7.so from glibc package for bluetooth file tranfer. But these libraries are not available in the rootfs, only files available under /usr/lib/gconv are gconv-modules and ISO8859-1.so. So I am trying to add these libraries by adding new bbappend file glibc_2.24.bbappend with the following content
FILES_${PN} += "${libdir}/gconv/*"
do_install_locale_append() {
cp -r ${dest}${libdir}/gconv ${D}${libdir}/
}
But it results in the following error:
ERROR: glibc-2.24-r0 do_populate_sysroot: The recipe glibc is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ISO-2022-CN.so Matched in b'manifest-esomimx7d-glibc-locale.populate_sysroot'
build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ARMSCII-8.so Matched in b'manifest-esomimx7d-glibc-locale.populate_sysroot'
......
Then I tried to remove the glibc-locale from the image but due to some dependency issues I could not do that.
Could anyone help me to add the above mentioned libraries to the rootfs?
The error is telling you the answer to your problem. Those files are part of the glibc-locale recipe, so you just need to install the right packages into the rootfs.
$ oe-pkgdata-util find-path \*/UTF-7.so
glibc-gconv-utf-7: /usr/lib/gconv/UTF-7.so
So you need to add glibc-gconv-utf-7 (or -utf-32, etc) to your image.
You can remove thm and compile again it will work.
rm build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ISO-2022-CN.so
rm build_dir/tmp/sysroots/esomimx7d/usr/lib/gconv/ARMSCII-8.so
This is for work around only we need for perminant sol.
These files are belongs to glibc-locale so you need to install the required packages.
$ oe-pkgdata-util find-path */UTF-7.so
glibc-gconv-utf-7:> /usr/lib/gconv/UTF-7.so
Add the glibc-gconv-utf-7 (or -utf-32, etc) to recipe image(e.g core-image-minimal).
I've got the pcre library installed via ports in /opt.
I'm trying to install pcre-light, but cabal install pcre-light reports:
Resolving dependencies...
Configuring pcre-light-0.4...
Preprocessing library pcre-light-0.4...
Base.hsc:103:18: error: pcre.h: No such file or directory
...
pcre.h is located in /opt/local/include
Update: I had trouble linking with the pcre library provided by macports, so I switched over to using home brew.
http://www.haskell.org/ghc/docs/7.0.2/html/Cabal/builders.html
--extra-include-dirs[=dir]
An extra directory to search for C header files. You can use this flag multiple times to get a list of directories.
You might need to use this flag if you have standard system header files in a non-standard location that is not mentioned in the package's .cabal file. Using this option has the same affect as appending the directory dir to the include-dirs field in each library and executable in the package's .cabal file. The advantage of course is that you do not have to modify the package at all. These extra directories will be used while building the package and for libraries it is also saved in the package registration information and used when compiling modules that use the library.