mirror of https://github.com/tLDP/LDP
87 lines
3.3 KiB
XML
87 lines
3.3 KiB
XML
<section id='scripts'>
|
|
<title>Scripts</title>
|
|
<para>
|
|
There are two very useful scripts in <filename>SPECS</filename>
|
|
module. One is called <command>builder</command>, second is
|
|
<command>adapter.awk</command>.
|
|
</para>
|
|
<section id="scripts.builder">
|
|
<title>Builder script</title>
|
|
<para>
|
|
<command>builder</command> can be used to:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Fetch spec file along with tarballs, patches, icons etc from CVS
|
|
repository, or if they are not stored there, from http/ftp URLs.
|
|
In order just to fetch files needed for build use
|
|
<literal>-g</literal> option. If you don't want to fetch Source0
|
|
(that is usually the hugest), use <literal>-ns0</literal> option.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Build binary and/or source RPMS. Use it without option, or with
|
|
<literal>-bs</literal> or <literal>-bb</literal> to do this.
|
|
It is used this on builder machines in PLD Linux.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Tag all files that constitutes package. Using
|
|
<literal>-T</literal> family of options one can add tags
|
|
not only for spec file, but also for patches and sources.
|
|
Note that having tags on all files in package is required to
|
|
make it build using <literal>-r</literal>
|
|
<command>builder</command> option. Even if you don't use
|
|
<command>builder -r</command> PLD builders does.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</section>
|
|
<section id="scripts.adapter">
|
|
<title>Adapter is your friend</title>
|
|
<para>
|
|
<command>adapter.awk</command> is tool fixing common mistakes in
|
|
spec files, and making them all look the same. There are some style
|
|
guidelines in PLD concerning spec files. They are mostly formalized
|
|
through few thousand examples in SPECS module and
|
|
<command>adapter.awk</command> script. While this probably isn't
|
|
very good way of formalization, this is how it works -- it is simply
|
|
recommended to run specs through <command>adapter.awk</command>
|
|
before doing commit.
|
|
</para>
|
|
<para>
|
|
<command>adapter.awk</command> reads spec file passed as first
|
|
argument or, if nothing is passed, standard input. Processed spec
|
|
is dumped on standard output.
|
|
</para>
|
|
<para>
|
|
For example, let's say you finally completed great
|
|
<filename>foo.spec</filename>:
|
|
<screen>
|
|
<prompt>[you@somewhere SPECS]$</prompt> ./adapter.awk foo.spec > foo.spec-
|
|
<prompt>[you@somewhere SPECS]$</prompt> diff -u foo.spec foo.spec-
|
|
...
|
|
<prompt>[you@somewhere SPECS]$</prompt> mv foo.spec- foo.spec
|
|
<prompt>[you@somewhere SPECS]$</prompt> cvs commit foo.spec
|
|
</screen>
|
|
</para>
|
|
<para>
|
|
You always should look at what <command>adapter.awk</command>
|
|
broke^H^H^H^H^Hchanged. It is just a piece of awk and it is sometimes
|
|
misled. Thats what's <command>diff</command> above is for.
|
|
</para>
|
|
<para>
|
|
If you use <command>vim</command> to edit spec files you might
|
|
find useful its diff mode, instead of using <command>diff</command>
|
|
command. Simply instead of <command>diff -u foo.spec foo.spec-</command>
|
|
run <command>vim -d foo.spec foo.spec-</command>.
|
|
</para>
|
|
<para>
|
|
FIXME: There is probably something similar in operating system Emacs.
|
|
</para>
|
|
</section>
|
|
</section>
|