pkgsrc/doc/guide/files/devfaq.xml

209 lines
7.8 KiB
XML

<!-- $NetBSD: devfaq.xml,v 1.11 2007/07/30 21:13:00 kano Exp $ -->
<chapter id="devfaq"> <?dbhtml filename="devfaq.html"?>
<title>Frequently Asked Questions</title>
<para>This section contains the answers to questions that may
arise when you are writing a package. If you don't find your
question answered here, first have a look in the other chapters,
and if you still don't have the answer, ask on the
<literal>pkgsrc-users</literal> mailing list.</para>
<qandaset>
<qandaentry id="devfaq.makeflags">
<question><para>What is the difference between
<varname>MAKEFLAGS</varname>, <varname>.MAKEFLAGS</varname> and
<varname>MAKE_FLAGS</varname>?</para></question>
<answer><para><varname>MAKEFLAGS</varname> are the flags passed
to the pkgsrc-internal invocations of &man.make.1;, while
<varname>MAKE_FLAGS</varname> are the flags that are passed to
the <varname>MAKE_PROGRAM</varname> when building the
package. [FIXME: What is .MAKEFLAGS for?]</para></answer>
</qandaentry>
<qandaentry id="devfaq.make">
<question><para>What is the difference between
<varname>MAKE</varname>, <varname>GMAKE</varname> and
<varname>MAKE_PROGRAM</varname>?</para></question>
<answer><para><varname>MAKE</varname> is the path to the
&man.make.1; program that is used in the pkgsrc
infrastructure. <varname>GMAKE</varname> is the path to GNU
Make, but you need to say <varname>USE_TOOLS+=gmake</varname> to
use that. <varname>MAKE_PROGRAM</varname> is the path to the
Make program that is used for building the
package.</para></answer>
</qandaentry>
<qandaentry id="devfaq.cc">
<question><para>What is the difference between
<varname>CC</varname>, <varname>PKG_CC</varname> and
<varname>PKGSRC_COMPILER</varname>?</para></question>
<answer><para><varname>CC</varname> is the path to the real C
compiler, which can be configured by the pkgsrc user.
<varname>PKG_CC</varname> is the path to the compiler wrapper.
<varname>PKGSRC_COMPILER</varname> is <emphasis>not</emphasis> a
path to a compiler, but the type of compiler that should be
used. See <filename>mk/compiler.mk</filename> for more
information about the latter variable.</para></answer>
</qandaentry>
<qandaentry id="devfaq.bl3flags">
<question><para>What is the difference between
<varname>BUILDLINK_LDFLAGS</varname>,
<varname>BUILDLINK_LDADD</varname> and
<varname>BUILDLINK_LIBS</varname>?</para></question>
<answer><para>[FIXME]</para></answer>
</qandaentry>
<qandaentry id="devfaq.bl3prefix">
<question><para>Why does <command>make show-var
VARNAME=BUILDLINK_PREFIX.<replaceable>foo</replaceable></command>
say it's empty?</para></question>
<answer><para>For optimization reasons, some variables are only
available in the <quote>wrapper</quote> phase and later. To
<quote>simulate</quote> the wrapper phase, append
<command>PKG_PHASE=wrapper</command> to the above
command.</para></answer>
</qandaentry>
<qandaentry id="devfaq.master_sites">
<question><para>What does
<literal>${MASTER_SITE_SOURCEFORGE:=package/}</literal> mean? I
don't understand the <literal>:=</literal> inside
it.</para></question>
<answer><para>The <literal>:=</literal> is not really an
assignment operator, like you might expect at first sight.
Instead, it is a degenerate form of
<literal>${LIST:<replaceable>old_string</replaceable>=<replaceable>new_string</replaceable>}</literal>,
which is documented in the &man.make.1; man page and which you
may have seen as in <literal>${SRCS:.c=.o}</literal>. In the
case of <varname>MASTER_SITE_*</varname>,
<replaceable>old_string</replaceable> is the empty string and
<replaceable>new_string</replaceable> is
<literal>package/</literal>. That's where the
<literal>:</literal> and the <literal>=</literal> fall
together.</para></answer>
</qandaentry>
<qandaentry id="devfaq.mailinglists">
<question><para>Which mailing lists are there for package
developers?</para></question>
<answer><variablelist>
<varlistentry><term><ulink
url="http://www.NetBSD.org/mailinglists/index.html#tech-pkg">tech-pkg</ulink></term>
<listitem><para>This is a list for technical discussions related
to pkgsrc development, e.g. soliciting feedback for changes to
pkgsrc infrastructure, proposed new features, questions related
to porting pkgsrc to a new platform, advice for maintaining a
package, patches that affect many packages, help requests moved
from pkgsrc-users when an infrastructure bug is found,
etc.</para></listitem></varlistentry>
<varlistentry><term><ulink
url="http://www.NetBSD.org/mailinglists/index.html#pkgsrc-bugs">pkgsrc-bugs</ulink></term>
<listitem><para>All bug reports in category "pkg" sent with
&man.send-pr.1; appear here. Please do not report your bugs here
directly; use one of the other mailing
lists.</para></listitem></varlistentry>
</variablelist></answer>
</qandaentry>
<qandaentry id="devfaq.documentation">
<question><para>Where is the pkgsrc
documentation?</para></question>
<answer><para>There are many places where you can find
documentation about pkgsrc:</para>
<itemizedlist>
<listitem><para>The pkgsrc guide (this document) is a collection
of chapters that explain large parts of pkgsrc, but some
chapters tend to be outdated. Which ones they are is hard to
say.</para></listitem>
<listitem><para>On the mailing list archives (see <ulink
url="http://mail-index.NetBSD.org/"/>), you can find discussions
about certain features, announcements of new parts of the pkgsrc
infrastructure and sometimes even announcements that a certain
feature has been marked as obsolete. The benefit here is that
each message has a date appended to it.</para></listitem>
<listitem><para>Many of the files in the
<filename>mk/</filename> directory start with a comment that
describes the purpose of the file and how it can be used by the
pkgsrc user and package authors. An easy way to find this
documentation is to run <command>bmake
help</command>.</para></listitem>
<listitem><para>The CVS log messages are a rich source of
information, but they tend to be highly abbreviated, especially
for actions that occur often. Some contain a detailed
description of what has changed, but they are geared towards the
other pkgsrc developers, not towards an average pkgsrc user.
They also only document <emphasis>changes</emphasis>, so if you
don't know what has been before, these messages may not be worth
too much to you.</para></listitem>
<listitem><para>Some parts of pkgsrc are only <quote>implicitly
documented</quote>, that is the documentation exists only in the
mind of the developer who wrote the code. To get this
information, use the <command>cvs annotate</command> command
to see who has written it and ask on the
<literal>tech-pkg</literal> mailing list, so that others can
find your questions later (see above). To be sure that the
developer in charge reads the mail, you may CC him or
her.</para></listitem>
</itemizedlist>
</answer>
</qandaentry>
<qandaentry id="devfaq.too-much-time">
<question><para>I have a little time to kill. What shall I
do?</para></question>
<answer><para>This is not really an FAQ yet, but here's the answer
anyway.</para>
<itemizedlist>
<listitem><para>Run <command>pkg_chk -N</command> (from the
<filename role="pkg">pkgtools/pkg_chk</filename> package). It
will tell you about newer versions of installed packages that are
available, but not yet updated in pkgsrc.</para></listitem>
<listitem><para>Browse <filename>pkgsrc/doc/TODO</filename>
&mdash; it contains a list of suggested new packages and a list of
cleanups and enhancements for pkgsrc that would be nice to
have.</para></listitem>
<listitem><para>Review packages for which review was requested on
the <ulink
url="http://pkgsrc-wip.sourceforge.net/">pkgsrc-wip</ulink> review
mailing list.</para></listitem>
</itemizedlist>
</answer></qandaentry>
</qandaset>
</chapter>