kumquat-buildroot/docs/manual/adding-packages-gettext.txt

62 lines
2.2 KiB
Plaintext
Raw Normal View History

// -*- mode:doc; -*-
// vim: set syntax=asciidoc:
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 07:47:30 +02:00
=== Gettext integration and interaction with packages
Many packages that support internationalization use the gettext
library. Dependencies for this library are fairly complicated and
therefore, deserve some explanation.
The 'uClibc' C library doesn't implement gettext functionality;
therefore with this C library, a separate gettext must be compiled,
which is provided by the additional +libintl+ library, part of the
+gettext+ package.
On the other hand, the 'glibc' C library does integrate its own
gettext library functions, so it is not necessary to build a separate
+libintl+ library.
However, certain packages need some gettext utilities on the target,
such as the +gettext+ program itself, which allows to retrieve
translated strings, from the command line.
Additionally, some packages (such as +libglib2+) do require gettext
functions unconditionally, while other packages (in general, those who
support +--disable-nls+) only require gettext functions when locale
support is enabled.
Therefore, Buildroot defines two configuration options:
* +BR2_NEEDS_GETTEXT+, which is true as soon as the toolchain doesn't
provide its own gettext implementation
* +BR2_NEEDS_GETTEXT_IF_LOCALE+, which is true if the toolchain
doesn't provide its own gettext implementation and if locale support
is enabled
Packages that need gettext only when locale support is enabled should:
* use +select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE+ in the
+Config.in+ file;
* use +$(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext)+ in the package
+DEPENDENCIES+ variable in the +.mk+ file.
Packages that unconditionally need gettext (which should be very rare)
should:
* use +select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT+ in the +Config.in+
file;
* use +$(if $(BR2_NEEDS_GETTEXT),gettext)+ in the package
+DEPENDENCIES+ variable in the +.mk+ file.
Packages that need the +gettext+ utilities on the target (should be
rare) should:
* use +select BR2_PACKAGE_GETTEXT+ in their +Config.in+ file,
indicating in a comment above that it's a runtime dependency only.
* not add any +gettext+ dependency in the +DEPENDENCIES+ variable of
their +.mk+ file.