glfs/introduction/welcome/conventions.xml
Fernando de Oliveira f34293095b • mupdf-1.8: minor reformat.
• removing spaces from EOL, from Denis Mugnier.
• BLFS/trunk/BOOK/kde/add/kdepim-runtime.xml: needed to fix to validate
  the book. One chunck had been removed. Bruce, please check if it is
  OK, now.


git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@16645 af4574ff-66df-0310-9fd7-8a98e5e911e0
2015-11-13 14:24:57 +00:00

244 lines
8.9 KiB
XML

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % general-entities SYSTEM "../../general.ent">
%general-entities;
]>
<sect1 id="conventions">
<?dbhtml filename="conventions.html"?>
<sect1info>
<othername>$LastChangedBy$</othername>
<date>$Date$</date>
</sect1info>
<title>Conventions Used in this Book</title>
<sect2>
<title>Typographical Conventions</title>
<para>To make things easy to follow, there are a number of conventions used
throughout the book. Following are some examples:</para>
<screen><userinput>./configure --prefix=/usr</userinput></screen>
<blockquote>
<para>This form of text is designed to be typed exactly as seen unless
otherwise noted in the surrounding text. It is also used to identify
references to specific commands.</para>
</blockquote>
<screen><computeroutput>install-info: unknown option
`--dir-file=/mnt/lfs/usr/info/dir'</computeroutput></screen>
<blockquote>
<para>This form of text (fixed width text) is showing screen
output, probably a result from issuing a command. It is also used to
show filenames such as <filename>/boot/grub/grub.conf</filename></para>
</blockquote>
<para><emphasis>Emphasis</emphasis></para>
<blockquote>
<para>This form of text is used for several purposes in the
book but mainly to emphasize important points or to give examples as to
what to type.</para>
</blockquote>
<para><ulink url="http://www.&lfs-domainname;/"/></para>
<blockquote>
<para>This form of text is used for hypertext links external to
the book such as HowTos, download locations, websites, etc.</para>
</blockquote>
<para><xref linkend="seamonkey"/></para>
<blockquote>
<para>This form of text is used for links internal to
the book such as another section describing a different package.</para>
</blockquote>
<screen><userinput>cat &gt; $LFS/etc/group &lt;&lt; "EOF"
<literal>root:x:0:
bin:x:1:
......</literal>
EOF</userinput></screen>
<blockquote>
<para>This type of section is used mainly when creating configuration
files. The first command (in bold) tells the system to create
the file <filename>$LFS/etc/group</filename> from whatever is typed on the
following lines until the sequence EOF is encountered.
Therefore, this whole section is generally typed as seen.</para>
</blockquote>
<para><replaceable>&lt;REPLACED TEXT&gt;</replaceable></para>
<blockquote>
<para>This form of text is used to encapsulate text that should be
modified and is not to be typed as seen, or copy and pasted. Note that
the square brackets are not part of the text, but should be substituted
for as well.</para>
</blockquote>
<para><systemitem class='username'>root</systemitem></para>
<blockquote>
<para>This form of text is used to show a specific system user or group
reference in the instructions.</para>
</blockquote>
</sect2>
<sect2>
<title>Conventions Used for Package Dependencies</title>
<para>When packages are created, the authors depend on prior work. In
order to build a package in BLFS, these dependencies must be built prior to
the desired package. For each package, any prerequsite packages are listed
in one or more separate sections: Required, Recommended, and Optional.</para>
<bridgehead renderas="sect3">Required Dependencies</bridgehead>
<para>These dependencies are the minimum prerequsite packages required to
build the package. Omitted from the list are packages in LFS and required
dependencies of other required packages.</para>
<bridgehead renderas="sect3">Recommended Dependencies</bridgehead>
<para>These dependencies are those that the BLFS editors have determined
are important to give the package reasonable capabilities. Package
installation instructions assume thay are installed. If a recommended
package is not desired, the instructions may need to be modified to
accommodate the missing package.</para>
<bridgehead renderas="sect3">Optional Dependencies</bridgehead>
<para>These dependencies are those that the package may use. Integration
of optional dependencies may be automatic by the package or may need
additional instructions not presented by BLFS. Optional packages may be
listed without corresponding BLFS instructions. In this case it is up to
the user to determine appropriate installation instructions. </para>
</sect2>
<sect2>
<title>Conventions Used for Kernel Configuration Options</title>
<para>Some packages have specific needs regarding the kernel configuration.
The general layout is the following:</para>
<screen><literal>Master section ---&gt;
Subsection ---&gt;
[*] Required parameter [CONFIG_REQU_PAR]
&lt;*&gt; Required parameter (not as module) [CONFIG_REQU_PAR_NMOD]
&lt;*/M&gt; Required parameter (could be a module) [CONFIG_REQU_PAR_MOD]
&lt;*/M/ &gt; Optional parameter [CONFIG_OPT_PAR]
[ ] Incompatible parameter [CONFIG_INCOMP_PAR]
&lt; &gt; Incompatible parameter (even as module) [CONFIG_INCOMP_PAR_MOD]</literal></screen>
<para>[CONFIG_...] on the right gives the name of the option, so you can
easily check whether it is set in your <filename>config</filename> file.
The meaning of the various entries is:
<blockquote>
<informaltable frame='none'><tgroup cols="2">
<colspec align="left"/><colspec align="left"/><tbody>
<row>
<entry><emphasis role="bold">Master section</emphasis></entry>
<entry>top level menu item</entry>
</row>
<row>
<entry><emphasis role="bold">Subsection</emphasis></entry>
<entry>submenu item</entry>
</row>
<row>
<entry>
<emphasis role="bold">Required parameter</emphasis></entry>
<entry>
the option could be either built-in or not selected: it must be
selected
</entry>
</row>
<row>
<entry>
<emphasis role="bold">Required parameter (not as
module)</emphasis>
</entry>
<entry>
the option could be either built-in, module, or not selected:
it must be selected as built-in
</entry>
</row>
<row>
<entry>
<emphasis role="bold">Required parameter (could be
a module)</emphasis>
</entry>
<entry>
the option could be either built-in, module, or not selected:
it must be selected, either as built-in or module
</entry>
</row>
<row>
<entry>
<emphasis role="bold">Optional parameter</emphasis>
</entry>
<entry>
rarely used: the option could be either built-in, module, or not
selected: it may be selected at will
</entry>
</row>
<row>
<entry>
<emphasis role="bold">Incompatible parameter</emphasis>
</entry>
<entry>
the option could be either built-in or not selected: it must
<emphasis>not</emphasis> be selected
</entry>
</row>
<row>
<entry>
<emphasis role="bold">Incompatible parameter (even as module)</emphasis>
</entry>
<entry>
the option could be either built-in, module, or not selected:
it must <emphasis>not</emphasis> be selected
</entry>
</row>
</tbody></tgroup></informaltable>
</blockquote>
</para>
<para>Note that, depending on other selections, the angle brackets
(&lt;&gt;) may appear as braces ({}), if the option cannot be unselected,
or even dashes (-*- or -M-), when the choice is imposed.
The help text about the option specifies the other selections on which this
option relies, and how those other selections are set.</para>
</sect2>
<sect2>
<title>SBU values in BLFS</title>
<para>As in LFS, each package in BLFS has a build time listed in Standard
Build Units (SBUs). These times are relative to the time it took to build
binutils in LFS and are intended to provide some insight into how long it
will take to build a package. Most times listed are for a single processor
or core to build the package. In some cases, large, long running builds
tested on multi-core systems have SBU times listed with comments such
as '(parallelism=4)'. These values indicate testing was done using
multiple cores. Note that while this speeds up the build on systems with
the appropriate hardware, the speedup is not linear and to some extent
depends on the individual package and specific hardware used. </para>
<para>Some packages do not support parallel builds and using -j1 for the
make command is required. Packages that are known to have such limits are
marked as such in the text.</para>
</sect2>
</sect1>