NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9587eea148
kumquat-buildroot/docs/manual/adding-packages-autotools.txt
Thomas De Schampheleire 86a415df8a manual: use one-line titles instead of two-line titles (trivial) 
Asciidoc supports two syntaxes for section titles: two-line titles (title
plus underline consisting of a particular symbol), and one-line titles
(title prefixed with a specific number of = signs).

The two-line title underlines are:
Level 0 (top level):     ======================
Level 1:                 ----------------------
Level 2:                 ~~~~~~~~~~~~~~~~~~~~~~
Level 3:                 ^^^^^^^^^^^^^^^^^^^^^^
Level 4 (bottom level):  ++++++++++++++++++++++

and the one-line title prefixes:
= Document Title (level 0) =
== Section title (level 1) ==

=== Section title (level 2) ===
==== Section title (level 3) ====
===== Section title (level 4) =====

The buildroot manual is currenly using the two-line titles, but this has
multiple disadvantages:

- asciidoc also uses some of the underline symbols for other purposes (like
  preformatted code, example blocks, ...), which makes it difficult to do
  mass replacements, such as a planned follow-up patch that needs to move
  all sections one level down.

- it is difficult to remember which level a given underline symbol (=-~^+)
  corresponds to, while counting = signs is easy.

This patch changes all two-level titles to one-level titles in the manual.
The bulk of the change was done with the following Python script, except for
the level 1 titles (-----) as these underlines are also used for literal
code blocks.
This patch only changes the titles, no other changes. In
adding-packages-directory.txt, I did add missing newlines between some
titles and their content.

----------------------------------------------------------------------------
#!/usr/bin/env python

import sys
import mmap
import re

for input in sys.argv[1:]:

    f = open(input, 'r+')
    f.flush()
    s = mmap.mmap(f.fileno(), 0)

    # Level 0 (top level):     ======================   =
    # Level 1:                 ----------------------   ==
    # Level 2:                 ~~~~~~~~~~~~~~~~~~~~~~   ===
    # Level 3:                 ^^^^^^^^^^^^^^^^^^^^^^   ====
    # Level 4 (bottom level):  ++++++++++++++++++++++   =====

    def replace_title(s, symbol, replacement):
        pattern = re.compile(r'(.+\n)\%s{2,}\n' % symbol, re.MULTILINE)
        return pattern.sub(r'%s \1' % replacement, s)

    new = s
    new = replace_title(new, '=', '=')
    new = replace_title(new, '+', '=====')
    new = replace_title(new, '^', '====')
    new = replace_title(new, '~', '===')
    #new = replace_title(new, '-', '==')

    s.seek(0)
    s.write(new)
    s.resize(s.tell())
    s.close()
    f.close()

----------------------------------------------------------------------------

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-02 10:27:59 +02:00

159 lines
6.5 KiB
Plaintext
Raw Blame History

// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
=== Infrastructure for autotools-based packages
[[autotools-package-tutorial]]
==== +autotools-package+ tutorial
First, let's see how to write a +.mk+ file for an autotools-based
package, with an example :
------------------------
01: ################################################################################
02: #
03: # libfoo
04: #
05: ################################################################################
06:
07: LIBFOO_VERSION = 1.0
08: LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
09: LIBFOO_SITE = http://www.foosoftware.org/download
10: LIBFOO_INSTALL_STAGING = YES
11: LIBFOO_INSTALL_TARGET = NO
12: LIBFOO_CONF_OPT = --disable-shared
13: LIBFOO_DEPENDENCIES = libglib2 host-pkgconf
14:
15: $(eval $(autotools-package))
------------------------
On line 7, we declare the version of the package.
On line 8 and 9, we declare the name of the tarball (xz-ed tarball recommended)
and the location of the tarball on the Web. Buildroot will automatically
download the tarball from this location.
On line 10, we tell Buildroot to install the package to the staging
directory. The staging directory, located in +output/staging/+
is the directory where all the packages are installed, including their
development files, etc. By default, packages are not installed to the
staging directory, since usually, only libraries need to be installed in
the staging directory: their development files are needed to compile
other libraries or applications depending on them. Also by default, when
staging installation is enabled, packages are installed in this location
using the +make install+ command.
On line 11, we tell Buildroot to not install the package to the
target directory. This directory contains what will become the root
filesystem running on the target. For purely static libraries, it is
not necessary to install them in the target directory because they will
not be used at runtime. By default, target installation is enabled; setting
this variable to NO is almost never needed. Also by default, packages are
installed in this location using the +make install+ command.
On line 12, we tell Buildroot to pass a custom configure option, that
will be passed to the +./configure+ script before configuring
and building the package.
On line 13, we declare our dependencies, so that they are built
before the build process of our package starts.
Finally, on line line 15, we invoke the +autotools-package+
macro that generates all the Makefile rules that actually allows the
package to be built.
[[autotools-package-reference]]
==== +autotools-package+ reference
The main macro of the autotools package infrastructure is
+autotools-package+. It is similar to the +generic-package+ macro. The ability to
have target and host packages is also available, with the
+host-autotools-package+ macro.
Just like the generic infrastructure, the autotools infrastructure
works by defining a number of variables before calling the
+autotools-package+ macro.
First, all the package metadata information variables that exist in the
generic infrastructure also exist in the autotools infrastructure:
+LIBFOO_VERSION+, +LIBFOO_SOURCE+,
+LIBFOO_PATCH+, +LIBFOO_SITE+,
+LIBFOO_SUBDIR+, +LIBFOO_DEPENDENCIES+,
+LIBFOO_INSTALL_STAGING+, +LIBFOO_INSTALL_TARGET+.
A few additional variables, specific to the autotools 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.
* +LIBFOO_SUBDIR+ may contain the name of a subdirectory
inside the package that contains the configure script. This is useful,
if for example, the main configure script is not at the root of the
tree extracted by the tarball. If +HOST_LIBFOO_SUBDIR+ is
not specified, it defaults to +LIBFOO_SUBDIR+.
* +LIBFOO_CONF_ENV+, to specify additional environment
variables to pass to the configure script. By default, empty.
* +LIBFOO_CONF_OPT+, to specify additional configure
options to pass to the configure script. By default, empty.
* +LIBFOO_MAKE+, to specify an alternate +make+
command. This is typically useful when parallel make is enabled in
the configuration (using +BR2_JLEVEL+) but that this
feature should be disabled for the given package, for one reason or
another. By default, set to +$(MAKE)+. If parallel building
is not supported by the package, then it should be set to
+LIBFOO_MAKE=$(MAKE1)+.
* +LIBFOO_MAKE_ENV+, to specify additional environment
variables to pass to make in the build step. These are passed before
the +make+ command. By default, empty.
* +LIBFOO_MAKE_OPT+, to specify additional variables to
pass to make in the build step. These are passed after the
+make+ command. By default, empty.
* +LIBFOO_AUTORECONF+, tells whether the package should
be autoreconfigured or not (i.e. if the configure script and
Makefile.in files should be re-generated by re-running autoconf,
automake, libtool, etc.). Valid values are +YES+ and
+NO+. By default, the value is +NO+
* +LIBFOO_AUTORECONF_OPT+ to specify additional options
passed to the 'autoreconf' program if
+LIBFOO_AUTORECONF=YES+. By default, empty.
* +LIBFOO_LIBTOOL_PATCH+ tells whether the Buildroot
patch to fix libtool cross-compilation issues should be applied or
not. Valid values are +YES+ and +NO+. By
default, the value is +YES+
* +LIBFOO_INSTALL_STAGING_OPT+ contains the make options
used to install the package to the staging directory. By default, the
value is +DESTDIR=$(STAGING_DIR) install+, which is
correct for most autotools packages. It is still possible to override
it.
* +LIBFOO_INSTALL_TARGET_OPT+ contains the make options
used to install the package to the target directory. By default, the
value is +DESTDIR=$(TARGET_DIR) install+. The default
value is correct for most autotools packages, but it is still possible
to override it if needed.
With the autotools infrastructure, all the steps required to build
and install the packages are already defined, and they generally work
well for most autotools-based packages. However, when required, it is
still possible to customize what is done in any particular step:
* By adding a post-operation hook (after extract, patch, configure,
build or install). See xref:hooks[] for details.
* By overriding one of the steps. For example, even if the autotools
infrastructure is used, if the package +.mk+ file defines its
own +LIBFOO_CONFIGURE_CMDS+ variable, it will be used
instead of the default autotools one. However, using this method
should be restricted to very specific cases. Do not use it in the
general case.
Reference in New Issue View Git Blame Copy Permalink