I created a Bitbake recipe that does two things: 1) build an out-of-tree kernel module, and 2) copy files into the target root filesystem.
Part 2) uses the update-alternatives class to choose which files to copy based on the package that's being installed, ie, ${PN}-package, similar to the way the "linux-firmware" recipe works.
I also use EXTRA_OEMAKE (as part of the modules class) to pass variables down to the Makefile for the module I'm building. What I would like to do is to select different variables in EXTRA_OEMAKE based on which package is specified, ie, package1, package2, etc.
Is there a way to do this, or can anyone suggest any alternatives?
Related
I am currently building an autotools-based package for buildroot but I only need some parts of the actual build output (shared libraries and a handful of tools). Is there a way to install only what I need, similar to debian's *.install files when a package should be split up (like a libfoo and libfoo-dev package). If there is no other way, I will have to use the LIBFOO_POST_INSTALL_TARGET_HOOKS but I would like to know if there is a better option.
I know of the LIBFOO_CONFIG_SCRIPTS variable, but this only remove files in the /bin directory and I would like to remove them from other places too (libexec, /var, ...). This method also feels hacky for non-config scripts related to that library.
If there are no autotools configure flags to alter the installation options, one simple method is to patch the Makefile.am as required.
Here are the steps :
Alter the source Makefile.am capturing your changes in a patch(s).
Copy your patches to the global patch directory, they will be applied before building the package.
Remove the package's output/build directory and rebuild it.
At this point, the undesired files will not be installed to the target.
The more detailed method for doing this is to "make package". Go to the package's src. Run quilt to auto-generate patches for you. Alter the sources (Makefile.am), refresh the patches. Copy the patches back to buildroot's global patch directory. Once done, buildroot will patch Makefile.am then it will generate the appropriate Makefiles and will not install as required.
Here is an example :
Assume you have set BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL)/patches"
make package
cd output/build/package
quilt init . # output/build/package/patches now exists
quilt new 001-Makefile.am.do.not.install.patch
quilt add src/Makefile.am
# you edit src/Makefile.am here
quilt refresh # now patches/001-Makefile.am.do.not.install.patch exists
mkdir patch/to/global/patches # see BR2_GLOBAL_PATCH_DIR above
cp patches/*.patch patch/to/global/patches
cd ../../.. # got back to buildroot root to make
rm -rf output/build/package
make package
At this point, your patches should be applied to the src code and the files you removed from the make install process will not be on the target.
Make sure PACKAGE_AUTORECONF = YES in the package.mk file, it forces buildroot to autoreconf.
I am writing a bitbake recipe to deploy a third party pre-built tool, similar to this wiki page: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
However, I have a Release and Debug pre-build versions of the tool available as *.so files. How do I distinguish inside the recipe which one of both build types I shall deploy?
Thanks and regards,
Martin
You can have two different virtual recipes each with their own .so file. This then warrants a selection in a configuration file (with PREFERRED_PROVIDER_virtual/my-recipe), so either in a machine or distro configuration file. This is probably preferred if you consider having release and debug distros.
A second option is to install the libraries in two different paths, in two different PACKAGES (use FILES_my-package for that) and make them RCONFLICTS_my-package each other to be sure they can't both be in the rootfs. After that, you could write a pkg_postinst_my-package() task specific to each package that actually move the library from the "different" path to the intended one. This will be run both at build time when creating the rootfs and at runtime on first boot, so you need to make sure to exclude one or the other (it's usually done by checking if ${D} exists, which does at build time but not runtime).
c.f.: http://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#post-installation-scripts
If you can manage to have both libraries installed in your rootfs and select the one you want with the LIBRARY_PATH environment variable, a simple recipe, with two packages with each library in a different location, will be sufficient.
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.
I am trying to link against the libconfig++ library using cmake. I installed the library
using apt-get so I am assuming it will have a .cmake file so I can use find_package. Problem is I don't know what package name to use. I tried libconfig, config, config++ as the package name to no avail.
As a general question, how does one find out which package is associated with a library.
I know that find_package looks into CMAKE_MODULE_PATH to see if there is a .cmake script. How to I find out what is the value of CMAKE_MODULE_PATH on my system. It's not an environment variable. I am running ubuntu 12.04.
Any help is appreciated.
To use find_package you need to have corresponding Find or Config cmake file. But library may not to provide it, seems with your library is such a case. You can use find_library for finding libraries and find_path to find include directories. With these commands you can even write FindXXX.cmake yourself.
CMAKE_MODULE_PATH is not an environment variable, it is CMake's one. This variable is intended for you to set, if you have additional directories with modules, by default it's empty. This is used in the "Module" mode. In this mode CMake searches FindXXX.cmake in the CMAKE_MODULE_PATH (your modules) or in modules shipped with CMake and if it's found, it then used to find library and it's headers.
If that module wasn't found, it then switches into "Config" mode. On Unix it searches for ConfigXXX.cmake in the following directories:
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/
This files is shipped with the library, so there is no need to find anything, they contain all information, where library and includes located, etc.
About naming scheme, there is no standard one. You can look at Standard CMake modules. Modules found in internet for your library named FindLibConfig.cmake
For your case, library ships without corresponding cmake file, so you should write it your self (or find already written) and add directory with that file to CMAKE_MODULE_PATH.
I suggest you to read how find_package command works and how to write FindXXX.cmake files.
I am working on a module that I would like to have two backends, a Module(::PerlArray) and Module::PDL (which can will depend on Module). Both need access to a functions.c/.h file for building. This file has the rather complicated logic needed for the module. Rather than distribute it separately with each module, is there some way to keep it with the Module::PP on the system and then add it to the appropriate build flags in EU::MM or M::B (given the complexity here probably the latter)?
To put it more visually
--Module--
Module.pm
Module/PerlArray.pm
Module/PerlArray.xs (#include functions.h
#include perlarray_backend.h)
Module/src/functions.c
Module/src/perlarray_backend.c
Module/inc/functions.h
Module/inc/perlarray_backend.h
--Module::PDL--
Module/PDL.pm
Module/PDL.xs (#include functions.h /*from Module*/
#include pdl_backend.h)
Module/src/pdl_backend.c
Module/inc/pdl_backend.h
and the compilation makes functions.o and links. I'm sure I can figure out how to set the flags appropriately but how can I make Module keep the functions.c file while installing, and how can I then find it when installing Module::PDL? Is there some location I can place the functions.c/.h?
Have you looked at DBI? It does what you suggest: it installs some .h file(s) that the DBD drivers can #include in their XS code, as well as a library that the DBD drivers can call.
Modules should be independently installable. That is, providing I have the pre-requisite Perl modules installed (but not necessarily still lying around in source form), then it should be possible to install all the modules in one distributed tar file without reference to the source for any other module.
You have options. One is to have a single source directory create several distributed tar balls, and they can each have a copy of the shared function.[ch] in the distributed source.
The other main option is to bundle both modules into a single distributed tar ball.