diff options
Diffstat (limited to 'docs/manual')
-rw-r--r-- | docs/manual/adding-packages-directory.txt | 10 | ||||
-rw-r--r-- | docs/manual/adding-packages-perl.txt | 120 | ||||
-rw-r--r-- | docs/manual/adding-packages.txt | 2 | ||||
-rw-r--r-- | docs/manual/configure.txt | 20 |
4 files changed, 140 insertions, 12 deletions
diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt index 40e543c8bd..6145f54479 100644 --- a/docs/manual/adding-packages-directory.txt +++ b/docs/manual/adding-packages-directory.txt @@ -235,7 +235,12 @@ use in the comment. * thread support ** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+ -** Comment string: +threads+ +** Comment string: +threads+ (unless +BR2_TOOLCHAIN_HAS_THREADS_NPTL+ + is also needed, in which case, specifying only +NPTL+ is sufficient) + +* NPTL thread support +** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS_NPTL+ +** Comment string: +NPTL+ * RPC support ** Dependency symbol: +BR2_TOOLCHAIN_HAS_NATIVE_RPC+ @@ -273,8 +278,7 @@ foo needs a toolchain w/ featA, featB, featC and a Linux kernel to be built Dependencies on udev /dev management ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If a package needs udev /dev management, it should depend on symbol -+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV+, and the following comment -should be added: ++BR2_PACKAGE_HAS_UDEV+, and the following comment should be added: -------------------------- foo needs udev /dev management diff --git a/docs/manual/adding-packages-perl.txt b/docs/manual/adding-packages-perl.txt new file mode 100644 index 0000000000..53aacbd11c --- /dev/null +++ b/docs/manual/adding-packages-perl.txt @@ -0,0 +1,120 @@ +// -*- mode:doc; -*- +// vim: set syntax=asciidoc: + +Infrastructure for Perl/CPAN packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +[[perl-package-tutorial]] + ++perl-package+ tutorial +^^^^^^^^^^^^^^^^^^^^^^^ + +First, let's see how to write a +.mk+ file for a Perl/CPAN package, +with an example : + +------------------------ +01: ################################################################################ +02: # +03: # perl-foo-bar +04: # +05: ################################################################################ +06: +07: PERL_FOO_BAR_VERSION = 0.02 +08: PERL_FOO_BAR_SOURCE = Foo-Bar-$(PERL_FOO_BAR_VERSION).tar.gz +09: PERL_FOO_BAR_SITE = $(BR2_CPAN_MIRROR)/authors/id/M/MO/MONGER/ +10: PERL_FOO_BAR_DEPENDENCIES = perl-strictures +11: PERL_FOO_BAR_LICENSE = Artistic or GPLv1+ +12: PERL_FOO_BAR_LICENSE_FILES = LICENSE +13: +14: $(eval $(perl-package)) +------------------------ + +On line 7, we declare the version of the package. + +On line 8 and 9, we declare the name of the tarball and the location +of the tarball on a CPAN server. Buildroot will automatically download +the tarball from this location. + +On line 10, we declare our dependencies, so that they are built +before the build process of our package starts. + +On line 11 and 12, we give licensing details about the package (its +license on line 11, and the file containing the license text on line +12). + +Finally, on line 14, we invoke the +perl-package+ macro that +generates all the Makefile rules that actually allow the package to be +built. + +Most of these data can be retrieved from https://metacpan.org/. +So, this file and the Config.in can be generated by running +the script +supports/scripts/scancpan Foo-Bar+ in the Buildroot directory +(or in the +BR2_EXTERNAL+ directory). +This script creates a Config.in file and foo-bar.mk file for the +requested package, and also recursively for all dependencies specified by +CPAN. You should still manually edit the result. In particular, the +following things should be checked. + +* The +PERL_FOO_BAR_LICENSE_FILES+ variable is not set, because metacpan + doesn't have this information. Also, the name of the license file(s) + varies between packages, and some don't even have a license file. +* If the perl module links with a shared library that is provided by + another (non-perl) package, this dependency is not added automatically. + It has to be added manually to +PERL_FOO_BAR_DEPENDENCIES+. +* The +package/Config.in+ file has to be updated manually to include the + generated Config.in files. As a hint, the +scancpan+ script prints out + the required +source "..."+ statements, sorted alphabetically. + +[[perl-package-reference]] + ++perl-package+ reference +^^^^^^^^^^^^^^^^^^^^^^^^ + +As a policy, packages that provide Perl/CPAN modules should all be +named +perl-<something>+ in Buildroot. + +This infrastructure handles various Perl build systems : ++ExtUtils-MakeMaker+, +Module-Build+ and +Module-Build-Tiny+. ++Build.PL+ is always preferred when a package provides a +Makefile.PL+ +and a +Build.PL+. + +The main macro of the Perl/CPAN package infrastructure is ++perl-package+. It is similar to the +generic-package+ macro. The ability to +have target and host packages is also available, with the ++host-perl-package+ macro. + +Just like the generic infrastructure, the Perl/CPAN infrastructure +works by defining a number of variables before calling the ++perl-package+ macro. + +First, all the package metadata information variables that exist in the +generic infrastructure also exist in the Perl/CPAN infrastructure: ++PERL_FOO_VERSION+, +PERL_FOO_SOURCE+, ++PERL_FOO_PATCH+, +PERL_FOO_SITE+, ++PERL_FOO_SUBDIR+, +PERL_FOO_DEPENDENCIES+, ++PERL_FOO_INSTALL_TARGET+. + +Note that setting +PERL_FOO_INSTALL_STAGING+ to +YES+ has no effect +unless a +PERL_FOO_INSTALL_STAGING_CMDS+ variable is defined. The perl +infrastructure doesn't define these commands since Perl modules generally +don't need to be installed to the +staging+ directory. + +A few additional variables, specific to the Perl/CPAN infrastructure, +can also be defined. Many of them are only useful in very specific +cases, typical packages will therefore only use a few of them. + +* +PERL_FOO_CONF_OPT+/+HOST_PERL_FOO_CONF_OPT+, to specify additional + configure options to pass to the +perl Makefile.PL+ or +perl Build.PL+. + By default, empty. + +* +PERL_FOO_BUILD_OPT+/+HOST_PERL_FOO_BUILD_OPT+, to specify additional + options to pass to +make pure_all+ or +perl Build build+ in the build step. + By default, empty. + +* +PERL_FOO_INSTALL_TARGET_OPT+, to specify additional options to + pass to +make pure_install+ or +perl Build install+ in the install step. + By default, empty. + +* +HOST_PERL_FOO_INSTALL_OPT+, to specify additional options to + pass to +make pure_install+ or +perl Build install+ in the install step. + By default, empty. diff --git a/docs/manual/adding-packages.txt b/docs/manual/adding-packages.txt index cc86529afb..745e33a2a1 100644 --- a/docs/manual/adding-packages.txt +++ b/docs/manual/adding-packages.txt @@ -22,6 +22,8 @@ include::adding-packages-python.txt[] include::adding-packages-luarocks.txt[] +include::adding-packages-perl.txt[] + include::adding-packages-hooks.txt[] include::adding-packages-gettext.txt[] diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt index 9a124405a4..badb6e473c 100644 --- a/docs/manual/configure.txt +++ b/docs/manual/configure.txt @@ -197,7 +197,7 @@ x86_64 target, you have to generate a cross-compilation toolchain with Buildroot or crosstool-NG. If you want to generate a custom toolchain for your project, that can -be used as an external toolchain in Buildroot, our recommandation is +be used as an external toolchain in Buildroot, our recommendation is definitely to build it with http://crosstool-ng.org[crosstool-NG]. We recommend to build the toolchain separately from Buildroot, and then _import_ it in Buildroot using the external toolchain backend. @@ -291,22 +291,24 @@ different solutions to handle the +/dev+ directory : about +mdev+ and the syntax of its configuration file, see http://git.busybox.net/busybox/tree/docs/mdev.txt. - * The fourth solution is *Dynamic using udev*. This method also + * The fourth solution is *Dynamic using eudev*. This method also relies on the _devtmpfs_ virtual filesystem detailed above, but - adds the +udev+ userspace daemon on top of it. +udev+ is a daemon + adds the +eudev+ userspace daemon on top of it. +eudev+ is a daemon that runs in the background, and gets called by the kernel when a device gets added or removed from the system. It is a more - heavyweight solution than +mdev+, but provides higher flexibility - and is sometimes mandatory for some system components (systemd for - example). +udev+ is the mechanism used in most desktop Linux - distributions. For more details about +udev+, see - http://en.wikipedia.org/wiki/Udev. + heavyweight solution than +mdev+, but provides higher flexibility. + +eudev+ is a standalone version of +udev+, the original userspace + daemon used in most desktop Linux distributions, which is now part + of Systemd. For more details, see http://en.wikipedia.org/wiki/Udev. -The Buildroot developers recommandation is to start with the *Dynamic +The Buildroot developers recommendation is to start with the *Dynamic using devtmpfs only* solution, until you have the need for userspace to be notified when devices are added/removed, or if firmwares are needed, in which case *Dynamic using mdev* is usually a good solution. +Note that if +systemd+ is chosen as init system, /dev management will +be performed by the +udev+ program provided by +systemd+. + init system ~~~~~~~~~~~ |