summaryrefslogtreecommitdiffstats
path: root/docs/manual
diff options
context:
space:
mode:
Diffstat (limited to 'docs/manual')
-rw-r--r--docs/manual/adding-packages-directory.txt10
-rw-r--r--docs/manual/adding-packages-perl.txt120
-rw-r--r--docs/manual/adding-packages.txt2
-rw-r--r--docs/manual/configure.txt20
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
~~~~~~~~~~~
OpenPOWER on IntegriCloud