regen.
This commit is contained in:
parent
9ceb6dda27
commit
3de5d1456f
2 changed files with 623 additions and 174 deletions
557
doc/pkgsrc.html
557
doc/pkgsrc.html
|
@ -66,8 +66,8 @@ alink="#0000FF">
|
|||
</div>
|
||||
|
||||
<div xmlns="http://www.w3.org/TR/xhtml1/transitional">
|
||||
<p xmlns="" class="pubdate">$NetBSD: pkgsrc.xml,v 1.14
|
||||
2006/05/10 20:56:00 rillig Exp $</p>
|
||||
<p xmlns="" class="pubdate">$NetBSD: pkgsrc.xml,v 1.16
|
||||
2006/05/12 23:03:22 rillig Exp $</p>
|
||||
</div>
|
||||
|
||||
<div>
|
||||
|
@ -1029,52 +1029,90 @@ alink="#0000FF">
|
|||
</dd>
|
||||
|
||||
<dt><span class="part"><a href="#infrastructure">III. The
|
||||
pkgsrc infrastructure</a></span></dt>
|
||||
pkgsrc infrastructure internals</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="chapter"><a href="#regression">20.
|
||||
<dt><span class="chapter"><a href="#infr.design">20.
|
||||
Design of the pkgsrc infrastructure</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href="#infr.var">20.1.
|
||||
Variable evaluation</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.var.load">20.1.1. At load
|
||||
time</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.var.run">20.1.2. At
|
||||
runtime</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#infr.design.intf">20.2. Designing interfaces for
|
||||
Makefile fragments</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.design.intf.proc">20.2.1. Procedures
|
||||
with parameters</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.design.intf.action">20.2.2. Actions
|
||||
taken on behalf of parameters</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="chapter"><a href="#regression">21.
|
||||
Regression tests</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.descr">20.1. The regression tests
|
||||
"#regression.descr">21.1. The regression tests
|
||||
framework</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.run">20.2. Running the regression
|
||||
"#regression.run">21.2. Running the regression
|
||||
tests</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.new">20.3. Adding a new regression
|
||||
"#regression.new">21.3. Adding a new regression
|
||||
test</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.override">20.3.1. Overridable
|
||||
"#regression.fun.override">21.3.1. Overridable
|
||||
functions</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.helper">20.3.2. Helper
|
||||
"#regression.fun.helper">21.3.2. Helper
|
||||
functions</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="chapter"><a href="#porting">21.
|
||||
<dt><span class="chapter"><a href="#porting">22.
|
||||
Porting pkgsrc</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.opsys">21.1. Porting pkgsrc to a new
|
||||
"#porting.opsys">22.1. Porting pkgsrc to a new
|
||||
operating system</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.compiler">21.2. Adding support for a new
|
||||
"#porting.compiler">22.2. Adding support for a new
|
||||
compiler</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
@ -1320,7 +1358,7 @@ alink="#0000FF">
|
|||
</div>
|
||||
</div>
|
||||
|
||||
<p>This document is divided into two parts. The first,
|
||||
<p>This document is divided into three parts. The first,
|
||||
<a href="#users-guide" title=
|
||||
"Part I. The pkgsrc user's guide">The pkgsrc
|
||||
user's guide</a>, describes how one can use one of the
|
||||
|
@ -1331,29 +1369,17 @@ alink="#0000FF">
|
|||
"Part II. The pkgsrc developer's guide">The
|
||||
pkgsrc developer's guide</a>, explains how to prepare a
|
||||
package so it can be easily built by other NetBSD users
|
||||
without knowing about the package's building details.</p>
|
||||
without knowing about the package's building details. The
|
||||
third part, <a href="#infrastructure" title=
|
||||
"Part III. The pkgsrc infrastructure internals">The
|
||||
pkgsrc infrastructure internals</a> is intended for those
|
||||
who want to understand how pkgsrc is implemented.</p>
|
||||
|
||||
<p>This document is available in various formats:</p>
|
||||
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p><a href="index.html" target="_top">HTML</a></p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p><a href="pkgsrc.pdf" target="_top">PDF</a></p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p><a href="pkgsrc.ps" target="_top">PS</a></p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p><a href="pkgsrc.txt" target="_top">TXT</a></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>This document is available in various formats:
|
||||
<span class="simplelist"><a href="index.html" target=
|
||||
"_top">HTML</a>, <a href="pkgsrc.pdf" target=
|
||||
"_top">PDF</a>, <a href="pkgsrc.ps" target="_top">PS</a>,
|
||||
<a href="pkgsrc.txt" target="_top">TXT</a></span>.</p>
|
||||
</div>
|
||||
|
||||
<div class="sect1" lang="en">
|
||||
|
@ -10418,21 +10444,21 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong>
|
|||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">Makefile</code>.</p>
|
||||
<pre class="programlisting">
|
||||
PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
|
||||
PKG_SUPPORTED_OPTIONS= wibble-foo ldap
|
||||
PKG_OPTIONS_OPTIONAL_GROUPS= database
|
||||
PKG_OPTIONS_GROUP.database= mysql pgsql
|
||||
PKG_SUGGESTED_OPTIONS= wibble-foo
|
||||
PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
|
||||
PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
|
||||
PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
|
||||
PKG_SUPPORTED_OPTIONS= wibble-foo ldap
|
||||
PKG_OPTIONS_OPTIONAL_GROUPS= database
|
||||
PKG_OPTIONS_GROUP.database= mysql pgsql
|
||||
PKG_SUGGESTED_OPTIONS= wibble-foo
|
||||
PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
|
||||
PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
|
||||
|
||||
.include "../../mk/bsd.prefs.mk"
|
||||
|
||||
# this package was previously named wibble2
|
||||
.if defined(PKG_OPTIONS.wibble2)
|
||||
PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
|
||||
PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
|
||||
PKG_OPTIONS_DEPRECATED_WARNINGS+= \
|
||||
"Deprecated variable PKG_OPTIONS.wibble2 used, use "${PKG_OPTIONS_VAR:Q}" instead."
|
||||
"Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR instead."
|
||||
.endif
|
||||
|
||||
.include "../../mk/bsd.options.mk"
|
||||
|
@ -15466,20 +15492,20 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
|
||||
<div class="qandaset">
|
||||
<dl>
|
||||
<dt>19.1. <a href="#id2654337">What is the difference
|
||||
<dt>19.1. <a href="#id2654342">What is the difference
|
||||
between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?</a></dt>
|
||||
|
||||
<dt>19.2. <a href="#id2654373">What is the difference
|
||||
<dt>19.2. <a href="#id2654378">What is the difference
|
||||
between MAKE, GMAKE and MAKE_PROGRAM?</a></dt>
|
||||
|
||||
<dt>19.3. <a href="#id2654411">What is the difference
|
||||
<dt>19.3. <a href="#id2654417">What is the difference
|
||||
between CC, PKG_CC and PKGSRC_COMPILER?</a></dt>
|
||||
|
||||
<dt>19.4. <a href="#id2654449">What is the difference
|
||||
<dt>19.4. <a href="#id2654454">What is the difference
|
||||
between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
|
||||
BUILDLINK_LIBS?</a></dt>
|
||||
|
||||
<dt>19.5. <a href="#id2654467">Why does make show-var
|
||||
<dt>19.5. <a href="#id2654472">Why does make show-var
|
||||
VARNAME=BUILDLINK_PREFIX.foo say it's empty?</a></dt>
|
||||
</dl>
|
||||
|
||||
|
@ -15489,8 +15515,8 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<tbody>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name=
|
||||
"id2654337"></a><a name=
|
||||
"id2654338"></a><b>19.1.</b></td>
|
||||
"id2654342"></a><a name=
|
||||
"id2654343"></a><b>19.1.</b></td>
|
||||
|
||||
<td align="left" valign="top">
|
||||
<p>What is the difference between <code class=
|
||||
|
@ -15519,8 +15545,8 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name=
|
||||
"id2654373"></a><a name=
|
||||
"id2654374"></a><b>19.2.</b></td>
|
||||
"id2654378"></a><a name=
|
||||
"id2654379"></a><b>19.2.</b></td>
|
||||
|
||||
<td align="left" valign="top">
|
||||
<p>What is the difference between <code class=
|
||||
|
@ -15551,8 +15577,8 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name=
|
||||
"id2654411"></a><a name=
|
||||
"id2654412"></a><b>19.3.</b></td>
|
||||
"id2654417"></a><a name=
|
||||
"id2654418"></a><b>19.3.</b></td>
|
||||
|
||||
<td align="left" valign="top">
|
||||
<p>What is the difference between <code class=
|
||||
|
@ -15583,8 +15609,8 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name=
|
||||
"id2654449"></a><a name=
|
||||
"id2654450"></a><b>19.4.</b></td>
|
||||
"id2654454"></a><a name=
|
||||
"id2654455"></a><b>19.4.</b></td>
|
||||
|
||||
<td align="left" valign="top">
|
||||
<p>What is the difference between <code class=
|
||||
|
@ -15604,8 +15630,8 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name=
|
||||
"id2654467"></a><a name=
|
||||
"id2654468"></a><b>19.5.</b></td>
|
||||
"id2654472"></a><a name=
|
||||
"id2654473"></a><b>19.5.</b></td>
|
||||
|
||||
<td align="left" valign="top">
|
||||
<p>Why does <span><strong class="command">make
|
||||
|
@ -15640,61 +15666,106 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<h1 class="title"><a name=
|
||||
"infrastructure"></a>Part III. The pkgsrc
|
||||
infrastructure</h1>
|
||||
infrastructure internals</h1>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<div class="partintro" lang="en">
|
||||
<p>This part of the guide deals with everything from the
|
||||
infrastructure that is behind the interfaces described in
|
||||
the developer's guide. A casual package maintainer should
|
||||
not need anything from this part.</p>
|
||||
|
||||
<dl>
|
||||
<dt><span class="chapter"><a href="#regression">20.
|
||||
Regression tests</a></span></dt>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.descr">20.1. The regression tests
|
||||
framework</a></span></dt>
|
||||
<dl>
|
||||
<dt><span class="chapter"><a href="#infr.design">20.
|
||||
Design of the pkgsrc infrastructure</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.run">20.2. Running the regression
|
||||
tests</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href="#infr.var">20.1.
|
||||
Variable evaluation</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.new">20.3. Adding a new regression
|
||||
test</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.var.load">20.1.1. At load
|
||||
time</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.override">20.3.1. Overridable
|
||||
functions</a></span></dt>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.var.run">20.1.2. At
|
||||
runtime</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.helper">20.3.2. Helper
|
||||
functions</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#infr.design.intf">20.2. Designing interfaces for
|
||||
Makefile fragments</a></span></dt>
|
||||
|
||||
<dt><span class="chapter"><a href="#porting">21. Porting
|
||||
pkgsrc</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.design.intf.proc">20.2.1. Procedures
|
||||
with parameters</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.opsys">21.1. Porting pkgsrc to a new
|
||||
operating system</a></span></dt>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.design.intf.action">20.2.2. Actions
|
||||
taken on behalf of parameters</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.compiler">21.2. Adding support for a new
|
||||
compiler</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
<dt><span class="chapter"><a href="#regression">21.
|
||||
Regression tests</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.descr">21.1. The regression tests
|
||||
framework</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.run">21.2. Running the regression
|
||||
tests</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.new">21.3. Adding a new regression
|
||||
test</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.override">21.3.1. Overridable
|
||||
functions</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.helper">21.3.2. Helper
|
||||
functions</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="chapter"><a href="#porting">22.
|
||||
Porting pkgsrc</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.opsys">22.1. Porting pkgsrc to a new
|
||||
operating system</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.compiler">22.2. Adding support for a new
|
||||
compiler</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="chapter" lang="en">
|
||||
|
@ -15702,7 +15773,259 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name=
|
||||
"regression"></a>Chapter 20. Regression
|
||||
"infr.design"></a>Chapter 20. Design of the
|
||||
pkgsrc infrastructure</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href="#infr.var">20.1.
|
||||
Variable evaluation</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.var.load">20.1.1. At load
|
||||
time</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.var.run">20.1.2. At runtime</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#infr.design.intf">20.2. Designing interfaces for
|
||||
Makefile fragments</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.design.intf.proc">20.2.1. Procedures with
|
||||
parameters</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#infr.design.intf.action">20.2.2. Actions taken on
|
||||
behalf of parameters</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
|
||||
<p>The pkgsrc infrastructure consists of many small
|
||||
Makefile fragments. Each such fragment needs a properly
|
||||
specified interface. This chapter explains how such an
|
||||
interface looks like.</p>
|
||||
|
||||
<div class="sect1" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"infr.var"></a>20.1. Variable evaluation</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="sect2" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name=
|
||||
"infr.var.load"></a>20.1.1. At load
|
||||
time</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<p>Variable evaluation takes place either at load time
|
||||
or at runtime, depending on the context in which they
|
||||
occur. The contexts where variables are evaluated at
|
||||
load time are:</p>
|
||||
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The right hand side of the <code class=
|
||||
"literal">:=</code> and <code class=
|
||||
"literal">!=</code> operators,</p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Make directives like <code class=
|
||||
"literal">.if</code> or <code class=
|
||||
"literal">.for</code>,</p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Dependency lines.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<p>A special exception are references to the iteration
|
||||
variables of <code class="literal">.for</code> loops,
|
||||
which are expanded inline, no matter in which context
|
||||
they appear.</p>
|
||||
|
||||
<p>As the values of variables may change during load
|
||||
time, care must be taken not to evaluate them by
|
||||
accident. Typical examples for variables that should
|
||||
not be evaluated at load time are <code class=
|
||||
"varname">DEPENDS</code> and <code class=
|
||||
"varname">CONFIGURE_ARGS</code>. To make the effect
|
||||
more clear, here is an example:</p>
|
||||
<pre class="programlisting">
|
||||
CONFIGURE_ARGS= # none
|
||||
CFLAGS= -O
|
||||
CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
|
||||
|
||||
CONFIGURE_ARGS:= ${CONFIGURE_ARGS}
|
||||
|
||||
CFLAGS+= -Wall
|
||||
|
||||
</pre>
|
||||
|
||||
<p>This code shows how the use of the <code class=
|
||||
"literal">:=</code> operator can quickly lead to
|
||||
unexpected results. The first paragraph is fairly
|
||||
common code. The second paragraph evaluates the
|
||||
<code class="varname">CONFIGURE_ARGS</code> variable,
|
||||
which results in <code class=
|
||||
"literal">CFLAGS=-O</code>. In the third paragraph, the
|
||||
<code class="literal">-Wall</code> is appended to the
|
||||
<code class="varname">CFLAGS</code>, but this addition
|
||||
will not appear in <code class=
|
||||
"varname">CONFIGURE_ARGS</code>. In actual code, the
|
||||
three paragraphs from above typically occur in
|
||||
completely unrelated files.</p>
|
||||
</div>
|
||||
|
||||
<div class="sect2" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name=
|
||||
"infr.var.run"></a>20.1.2. At runtime</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<p>After all the files have been loaded, the values of
|
||||
the variables cannot be changed anymore. Variables that
|
||||
are used in the shell commands are expanded at this
|
||||
point.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="sect1" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"infr.design.intf"></a>20.2. Designing
|
||||
interfaces for Makefile fragments</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<p>Most of the <code xmlns=
|
||||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">.mk</code> files fall into one of the
|
||||
following classes. Cases where a file falls into more
|
||||
than one class should be avoided as it often leads to
|
||||
subtle bugs.</p>
|
||||
|
||||
<div class="sect2" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name=
|
||||
"infr.design.intf.proc"></a>20.2.1. Procedures
|
||||
with parameters</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<p>In a traditional imperative programming language
|
||||
some of the <code xmlns=
|
||||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">.mk</code> files could be described as
|
||||
procedures. They take some input parameters
|
||||
and—after inclusion—provide a result in
|
||||
output parameters. Since all variables in <code xmlns=
|
||||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">Makefile</code>s have global scope care must
|
||||
be taken not to use parameter names that have already
|
||||
another meaning. For example, <code class=
|
||||
"varname">PKGNAME</code> is a bad choice for a
|
||||
parameter name.</p>
|
||||
|
||||
<p>Procedures are completely evaluated at preprocessing
|
||||
time. That is, when calling a procedure all input
|
||||
parameters must be completely resolvable. For example,
|
||||
<code class="varname">CONFIGURE_ARGS</code> should
|
||||
never be an input parameter since it is very likely
|
||||
that further text will be added after calling the
|
||||
procedure, which would effectively apply the procedure
|
||||
to only a part of the variable. Also, references to
|
||||
other variables wit will be modified after calling the
|
||||
procedure.</p>
|
||||
|
||||
<p>A procedure can declare its output parameters either
|
||||
as suitable for use in preprocessing directives or as
|
||||
only available at runtime. The latter alternative is
|
||||
for variables that contain references to other runtime
|
||||
variables.</p>
|
||||
|
||||
<p>Procedures shall be written such that it is possible
|
||||
to call the procedure more than once. That is, the file
|
||||
must not contain multiple-inclusion guards.</p>
|
||||
|
||||
<p>Examples for procedures are <code xmlns=
|
||||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">mk/bsd.options.mk</code> and <code xmlns=
|
||||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">mk/buildlink3/bsd.builtin.mk</code>. To
|
||||
express that the parameters are evaluated at load time,
|
||||
they should be assigned using the <code class=
|
||||
"literal">:=</code> operator, which should be used only
|
||||
for this purpose.</p>
|
||||
</div>
|
||||
|
||||
<div class="sect2" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name=
|
||||
"infr.design.intf.action"></a>20.2.2. Actions
|
||||
taken on behalf of parameters</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<p>Action files take some input parameters and may
|
||||
define runtime variables. They shall not define
|
||||
loadtime variables. There are action files that are
|
||||
included implicitly by the pkgsrc infrastructure, while
|
||||
other must be included explicitly.</p>
|
||||
|
||||
<p>An example for action files is <code xmlns=
|
||||
"http://www.w3.org/TR/xhtml1/transitional" class=
|
||||
"filename">mk/subst.mk</code>.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name=
|
||||
"regression"></a>Chapter 21. Regression
|
||||
tests</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15713,23 +16036,23 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href=
|
||||
"#regression.descr">20.1. The regression tests
|
||||
"#regression.descr">21.1. The regression tests
|
||||
framework</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href="#regression.run">20.2.
|
||||
<dt><span class="sect1"><a href="#regression.run">21.2.
|
||||
Running the regression tests</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href="#regression.new">20.3.
|
||||
<dt><span class="sect1"><a href="#regression.new">21.3.
|
||||
Adding a new regression test</a></span></dt>
|
||||
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.override">20.3.1. Overridable
|
||||
"#regression.fun.override">21.3.1. Overridable
|
||||
functions</a></span></dt>
|
||||
|
||||
<dt><span class="sect2"><a href=
|
||||
"#regression.fun.helper">20.3.2. Helper
|
||||
"#regression.fun.helper">21.3.2. Helper
|
||||
functions</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
|
@ -15750,7 +16073,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"regression.descr"></a>20.1. The regression
|
||||
"regression.descr"></a>21.1. The regression
|
||||
tests framework</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15762,7 +16085,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"regression.run"></a>20.2. Running the
|
||||
"regression.run"></a>21.2. Running the
|
||||
regression tests</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15786,7 +16109,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"regression.new"></a>20.3. Adding a new
|
||||
"regression.new"></a>21.3. Adding a new
|
||||
regression test</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15808,7 +16131,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name=
|
||||
"regression.fun.override"></a>20.3.1. Overridable
|
||||
"regression.fun.override"></a>21.3.1. Overridable
|
||||
functions</h3>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15871,7 +16194,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name=
|
||||
"regression.fun.helper"></a>20.3.2. Helper
|
||||
"regression.fun.helper"></a>21.3.2. Helper
|
||||
functions</h3>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15924,7 +16247,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name=
|
||||
"porting"></a>Chapter 21. Porting
|
||||
"porting"></a>Chapter 22. Porting
|
||||
pkgsrc</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -15934,12 +16257,12 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<p><b>Table of Contents</b></p>
|
||||
|
||||
<dl>
|
||||
<dt><span class="sect1"><a href="#porting.opsys">21.1.
|
||||
<dt><span class="sect1"><a href="#porting.opsys">22.1.
|
||||
Porting pkgsrc to a new operating
|
||||
system</a></span></dt>
|
||||
|
||||
<dt><span class="sect1"><a href=
|
||||
"#porting.compiler">21.2. Adding support for a new
|
||||
"#porting.compiler">22.2. Adding support for a new
|
||||
compiler</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
|
@ -15954,7 +16277,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"porting.opsys"></a>21.1. Porting pkgsrc to a
|
||||
"porting.opsys"></a>22.1. Porting pkgsrc to a
|
||||
new operating system</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
@ -16077,7 +16400,7 @@ TOOLS_PLATFORM.true?= true # shell builtin
|
|||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"porting.compiler"></a>21.2. Adding support
|
||||
"porting.compiler"></a>22.2. Adding support
|
||||
for a new compiler</h2>
|
||||
</div>
|
||||
</div>
|
||||
|
|
240
doc/pkgsrc.txt
240
doc/pkgsrc.txt
|
@ -14,7 +14,7 @@ The pkgsrc Developers
|
|||
|
||||
Copyright (C) 1994-2005 The NetBSD Foundation, Inc
|
||||
|
||||
$NetBSD: pkgsrc.xml,v 1.14 2006/05/10 20:56:00 rillig Exp $
|
||||
$NetBSD: pkgsrc.xml,v 1.16 2006/05/12 23:03:22 rillig Exp $
|
||||
|
||||
Abstract
|
||||
|
||||
|
@ -291,21 +291,33 @@ II. The pkgsrc developer's guide
|
|||
|
||||
19. Frequently Asked Questions
|
||||
|
||||
III. The pkgsrc infrastructure
|
||||
III. The pkgsrc infrastructure internals
|
||||
|
||||
20. Regression tests
|
||||
20. Design of the pkgsrc infrastructure
|
||||
|
||||
20.1. The regression tests framework
|
||||
20.2. Running the regression tests
|
||||
20.3. Adding a new regression test
|
||||
20.1. Variable evaluation
|
||||
|
||||
20.3.1. Overridable functions
|
||||
20.3.2. Helper functions
|
||||
20.1.1. At load time
|
||||
20.1.2. At runtime
|
||||
|
||||
21. Porting pkgsrc
|
||||
20.2. Designing interfaces for Makefile fragments
|
||||
|
||||
21.1. Porting pkgsrc to a new operating system
|
||||
21.2. Adding support for a new compiler
|
||||
20.2.1. Procedures with parameters
|
||||
20.2.2. Actions taken on behalf of parameters
|
||||
|
||||
21. Regression tests
|
||||
|
||||
21.1. The regression tests framework
|
||||
21.2. Running the regression tests
|
||||
21.3. Adding a new regression test
|
||||
|
||||
21.3.1. Overridable functions
|
||||
21.3.2. Helper functions
|
||||
|
||||
22. Porting pkgsrc
|
||||
|
||||
22.1. Porting pkgsrc to a new operating system
|
||||
22.2. Adding support for a new compiler
|
||||
|
||||
A. A simple example package: bison
|
||||
|
||||
|
@ -393,22 +405,16 @@ platforms:
|
|||
|
||||
1.2. Overview
|
||||
|
||||
This document is divided into two parts. The first, The pkgsrc user's guide,
|
||||
This document is divided into three parts. The first, The pkgsrc user's guide,
|
||||
describes how one can use one of the packages in the Package Collection, either
|
||||
by installing a precompiled binary package, or by building one's own copy using
|
||||
the NetBSD package system. The second part, The pkgsrc developer's guide,
|
||||
explains how to prepare a package so it can be easily built by other NetBSD
|
||||
users without knowing about the package's building details.
|
||||
users without knowing about the package's building details. The third part, The
|
||||
pkgsrc infrastructure internals is intended for those who want to understand
|
||||
how pkgsrc is implemented.
|
||||
|
||||
This document is available in various formats:
|
||||
|
||||
* HTML
|
||||
|
||||
* PDF
|
||||
|
||||
* PS
|
||||
|
||||
* TXT
|
||||
This document is available in various formats: HTML, PDF, PS, TXT.
|
||||
|
||||
1.3. Terminology
|
||||
|
||||
|
@ -3919,21 +3925,21 @@ The following example shows how bsd.options.mk should be used by the
|
|||
hypothetical ``wibble'' package, either in the package Makefile, or in a file,
|
||||
e.g. options.mk, that is included by the main package Makefile.
|
||||
|
||||
PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
|
||||
PKG_SUPPORTED_OPTIONS= wibble-foo ldap
|
||||
PKG_OPTIONS_OPTIONAL_GROUPS= database
|
||||
PKG_OPTIONS_GROUP.database= mysql pgsql
|
||||
PKG_SUGGESTED_OPTIONS= wibble-foo
|
||||
PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
|
||||
PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
|
||||
PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
|
||||
PKG_SUPPORTED_OPTIONS= wibble-foo ldap
|
||||
PKG_OPTIONS_OPTIONAL_GROUPS= database
|
||||
PKG_OPTIONS_GROUP.database= mysql pgsql
|
||||
PKG_SUGGESTED_OPTIONS= wibble-foo
|
||||
PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap
|
||||
PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo
|
||||
|
||||
.include "../../mk/bsd.prefs.mk"
|
||||
|
||||
# this package was previously named wibble2
|
||||
.if defined(PKG_OPTIONS.wibble2)
|
||||
PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
|
||||
PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2}
|
||||
PKG_OPTIONS_DEPRECATED_WARNINGS+= \
|
||||
"Deprecated variable PKG_OPTIONS.wibble2 used, use "${PKG_OPTIONS_VAR:Q}" instead."
|
||||
"Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR instead."
|
||||
.endif
|
||||
|
||||
.include "../../mk/bsd.options.mk"
|
||||
|
@ -6052,34 +6058,154 @@ pkgsrc-users mailing list.
|
|||
"wrapper" phase and later. To "simulate" the wrapper phase, append
|
||||
PKG_PHASE=wrapper to the above command.
|
||||
|
||||
Part III. The pkgsrc infrastructure
|
||||
Part III. The pkgsrc infrastructure internals
|
||||
|
||||
This part of the guide deals with everything from the infrastructure that is
|
||||
behind the interfaces described in the developer's guide. A casual package
|
||||
maintainer should not need anything from this part.
|
||||
|
||||
Table of Contents
|
||||
|
||||
20. Regression tests
|
||||
20. Design of the pkgsrc infrastructure
|
||||
|
||||
20.1. The regression tests framework
|
||||
20.2. Running the regression tests
|
||||
20.3. Adding a new regression test
|
||||
20.1. Variable evaluation
|
||||
|
||||
20.3.1. Overridable functions
|
||||
20.3.2. Helper functions
|
||||
20.1.1. At load time
|
||||
20.1.2. At runtime
|
||||
|
||||
21. Porting pkgsrc
|
||||
20.2. Designing interfaces for Makefile fragments
|
||||
|
||||
21.1. Porting pkgsrc to a new operating system
|
||||
21.2. Adding support for a new compiler
|
||||
20.2.1. Procedures with parameters
|
||||
20.2.2. Actions taken on behalf of parameters
|
||||
|
||||
Chapter 20. Regression tests
|
||||
21. Regression tests
|
||||
|
||||
21.1. The regression tests framework
|
||||
21.2. Running the regression tests
|
||||
21.3. Adding a new regression test
|
||||
|
||||
21.3.1. Overridable functions
|
||||
21.3.2. Helper functions
|
||||
|
||||
22. Porting pkgsrc
|
||||
|
||||
22.1. Porting pkgsrc to a new operating system
|
||||
22.2. Adding support for a new compiler
|
||||
|
||||
Chapter 20. Design of the pkgsrc infrastructure
|
||||
|
||||
Table of Contents
|
||||
|
||||
20.1. The regression tests framework
|
||||
20.2. Running the regression tests
|
||||
20.3. Adding a new regression test
|
||||
20.1. Variable evaluation
|
||||
|
||||
20.3.1. Overridable functions
|
||||
20.3.2. Helper functions
|
||||
20.1.1. At load time
|
||||
20.1.2. At runtime
|
||||
|
||||
20.2. Designing interfaces for Makefile fragments
|
||||
|
||||
20.2.1. Procedures with parameters
|
||||
20.2.2. Actions taken on behalf of parameters
|
||||
|
||||
The pkgsrc infrastructure consists of many small Makefile fragments. Each such
|
||||
fragment needs a properly specified interface. This chapter explains how such
|
||||
an interface looks like.
|
||||
|
||||
20.1. Variable evaluation
|
||||
|
||||
20.1.1. At load time
|
||||
|
||||
Variable evaluation takes place either at load time or at runtime, depending on
|
||||
the context in which they occur. The contexts where variables are evaluated at
|
||||
load time are:
|
||||
|
||||
* The right hand side of the := and != operators,
|
||||
|
||||
* Make directives like .if or .for,
|
||||
|
||||
* Dependency lines.
|
||||
|
||||
A special exception are references to the iteration variables of .for loops,
|
||||
which are expanded inline, no matter in which context they appear.
|
||||
|
||||
As the values of variables may change during load time, care must be taken not
|
||||
to evaluate them by accident. Typical examples for variables that should not be
|
||||
evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
|
||||
clear, here is an example:
|
||||
|
||||
CONFIGURE_ARGS= # none
|
||||
CFLAGS= -O
|
||||
CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q}
|
||||
|
||||
CONFIGURE_ARGS:= ${CONFIGURE_ARGS}
|
||||
|
||||
CFLAGS+= -Wall
|
||||
|
||||
|
||||
This code shows how the use of the := operator can quickly lead to unexpected
|
||||
results. The first paragraph is fairly common code. The second paragraph
|
||||
evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
|
||||
paragraph, the -Wall is appended to the CFLAGS, but this addition will not
|
||||
appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
|
||||
typically occur in completely unrelated files.
|
||||
|
||||
20.1.2. At runtime
|
||||
|
||||
After all the files have been loaded, the values of the variables cannot be
|
||||
changed anymore. Variables that are used in the shell commands are expanded at
|
||||
this point.
|
||||
|
||||
20.2. Designing interfaces for Makefile fragments
|
||||
|
||||
Most of the .mk files fall into one of the following classes. Cases where a
|
||||
file falls into more than one class should be avoided as it often leads to
|
||||
subtle bugs.
|
||||
|
||||
20.2.1. Procedures with parameters
|
||||
|
||||
In a traditional imperative programming language some of the .mk files could be
|
||||
described as procedures. They take some input parameters and?after inclusion?
|
||||
provide a result in output parameters. Since all variables in Makefiles have
|
||||
global scope care must be taken not to use parameter names that have already
|
||||
another meaning. For example, PKGNAME is a bad choice for a parameter name.
|
||||
|
||||
Procedures are completely evaluated at preprocessing time. That is, when
|
||||
calling a procedure all input parameters must be completely resolvable. For
|
||||
example, CONFIGURE_ARGS should never be an input parameter since it is very
|
||||
likely that further text will be added after calling the procedure, which would
|
||||
effectively apply the procedure to only a part of the variable. Also,
|
||||
references to other variables wit will be modified after calling the procedure.
|
||||
|
||||
A procedure can declare its output parameters either as suitable for use in
|
||||
preprocessing directives or as only available at runtime. The latter
|
||||
alternative is for variables that contain references to other runtime
|
||||
variables.
|
||||
|
||||
Procedures shall be written such that it is possible to call the procedure more
|
||||
than once. That is, the file must not contain multiple-inclusion guards.
|
||||
|
||||
Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
|
||||
To express that the parameters are evaluated at load time, they should be
|
||||
assigned using the := operator, which should be used only for this purpose.
|
||||
|
||||
20.2.2. Actions taken on behalf of parameters
|
||||
|
||||
Action files take some input parameters and may define runtime variables. They
|
||||
shall not define loadtime variables. There are action files that are included
|
||||
implicitly by the pkgsrc infrastructure, while other must be included
|
||||
explicitly.
|
||||
|
||||
An example for action files is mk/subst.mk.
|
||||
|
||||
Chapter 21. Regression tests
|
||||
|
||||
Table of Contents
|
||||
|
||||
21.1. The regression tests framework
|
||||
21.2. Running the regression tests
|
||||
21.3. Adding a new regression test
|
||||
|
||||
21.3.1. Overridable functions
|
||||
21.3.2. Helper functions
|
||||
|
||||
The pkgsrc infrastructure consists of a large codebase, and there are many
|
||||
corners where every little bit of a file is well thought out, making pkgsrc
|
||||
|
@ -6088,22 +6214,22 @@ changes from breaking anything, a suite of regression tests should go along
|
|||
with every important part of the pkgsrc infrastructure. This chapter describes
|
||||
how regression tests work in pkgsrc and how you can add new tests.
|
||||
|
||||
20.1. The regression tests framework
|
||||
21.1. The regression tests framework
|
||||
|
||||
20.2. Running the regression tests
|
||||
21.2. Running the regression tests
|
||||
|
||||
You first need to install the pkgtools/pkg_regress package, which provides the
|
||||
pkg_regress command. Then you can simply run that command, which will run all
|
||||
tests in the regress category.
|
||||
|
||||
20.3. Adding a new regression test
|
||||
21.3. Adding a new regression test
|
||||
|
||||
Every directory in the regress category that contains a file called spec is
|
||||
considered a regression test. This file is a shell program that is included by
|
||||
the pkg_regress command. The following functions can be overridden to suit your
|
||||
needs.
|
||||
|
||||
20.3.1. Overridable functions
|
||||
21.3.1. Overridable functions
|
||||
|
||||
These functions do not take any parameters. They are all called in "set -e"
|
||||
mode, so you should be careful to check the exitcodes of any commands you run
|
||||
|
@ -6131,7 +6257,7 @@ do_cleanup()
|
|||
This function cleans everything up after the test has been run. By default
|
||||
it does nothing.
|
||||
|
||||
20.3.2. Helper functions
|
||||
21.3.2. Helper functions
|
||||
|
||||
exit_status(expected)
|
||||
|
||||
|
@ -6150,18 +6276,18 @@ output_prohibit(regex...)
|
|||
() does not match the extended regular expression. If any of the regular
|
||||
expressions matches, the test will fail.
|
||||
|
||||
Chapter 21. Porting pkgsrc
|
||||
Chapter 22. Porting pkgsrc
|
||||
|
||||
Table of Contents
|
||||
|
||||
21.1. Porting pkgsrc to a new operating system
|
||||
21.2. Adding support for a new compiler
|
||||
22.1. Porting pkgsrc to a new operating system
|
||||
22.2. Adding support for a new compiler
|
||||
|
||||
The pkgsrc system has already been ported to many operating systems, hardware
|
||||
architectures and compilers. This chapter explains the necessary steps to make
|
||||
pkgsrc even more portable.
|
||||
|
||||
21.1. Porting pkgsrc to a new operating system
|
||||
22.1. Porting pkgsrc to a new operating system
|
||||
|
||||
To port pkgsrc to a new operating system (called MyOS in this example), you
|
||||
need to touch the following files:
|
||||
|
@ -6209,7 +6335,7 @@ mk/tools/MyOS.mk
|
|||
Now, you should be able to build some basic packages, like lang/perl5, shells/
|
||||
bash.
|
||||
|
||||
21.2. Adding support for a new compiler
|
||||
22.2. Adding support for a new compiler
|
||||
|
||||
TODO
|
||||
|
||||
|
|
Loading…
Reference in a new issue