diff options
| author | rillig <rillig@pkgsrc.org> | 2005-11-03 20:46:21 +0000 |
|---|---|---|
| committer | rillig <rillig@pkgsrc.org> | 2005-11-03 20:46:21 +0000 |
| commit | 898b4b55faa8d56f174f2e69d8ddd3cbd713577a (patch) | |
| tree | 69e75666bbecb99246959ff07b09148054512b8b | |
| parent | 3c1d64edcd01cb7156141bbd91c18757f7bf706e (diff) | |
| download | pkgsrc-898b4b55faa8d56f174f2e69d8ddd3cbd713577a.tar.gz | |
regen.
| -rw-r--r-- | doc/pkgsrc.html | 913 | ||||
| -rw-r--r-- | doc/pkgsrc.txt | 365 |
2 files changed, 888 insertions, 390 deletions
diff --git a/doc/pkgsrc.html b/doc/pkgsrc.html index ed10fa42c66..fc1955655c1 100644 --- a/doc/pkgsrc.html +++ b/doc/pkgsrc.html @@ -680,14 +680,77 @@ alink="#0000FF"> <dd> <dl> <dt><span class="sect1"><a href= - "#build.prefix">14.1. Program + "#build.intro">14.1. Introduction</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.prefix">14.2. Program location</a></span></dt> <dt><span class="sect1"><a href= - "#main-targets">14.2. Main targets</a></span></dt> + "#build.builddirs">14.3. Directories used during + the build process</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.running">14.4. Running a + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.fetch">14.5. The <span class= + "emphasis"><em>fetch</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.checksum">14.6. The <span class= + "emphasis"><em>checksum</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.extract">14.7. The <span class= + "emphasis"><em>extract</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.patch">14.8. The <span class= + "emphasis"><em>patch</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.tools">14.9. The <span class= + "emphasis"><em>tools</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.wrapper">14.10. The <span class= + "emphasis"><em>wrapper</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.configure">14.11. The <span class= + "emphasis"><em>configure</em></span> + phase</a></span></dt> <dt><span class="sect1"><a href= - "#build.helpful-targets">14.3. Other helpful + "#build.build">14.12. The <span class= + "emphasis"><em>build</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.test">14.13. The <span class= + "emphasis"><em>test</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.install">14.14. The <span class= + "emphasis"><em>install</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.package">14.15. The <span class= + "emphasis"><em>package</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.helpful-targets">14.16. Other helpful targets</a></span></dt> </dl> </dd> @@ -3892,7 +3955,7 @@ alink="#0000FF"> </div> <p>See <a href="#build.helpful-targets" title= - "14.3. Other helpful targets">Section 14.3, + "14.16. Other helpful targets">Section 14.16, “Other helpful targets”</a>.</p> </div> @@ -5990,14 +6053,72 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> <dd> <dl> - <dt><span class="sect1"><a href="#build.prefix">14.1. + <dt><span class="sect1"><a href="#build.intro">14.1. + Introduction</a></span></dt> + + <dt><span class="sect1"><a href="#build.prefix">14.2. Program location</a></span></dt> - <dt><span class="sect1"><a href="#main-targets">14.2. - Main targets</a></span></dt> + <dt><span class="sect1"><a href= + "#build.builddirs">14.3. Directories used during the + build process</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.running">14.4. Running a + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.fetch">14.5. + The <span class="emphasis"><em>fetch</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.checksum">14.6. The <span class= + "emphasis"><em>checksum</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.extract">14.7. The <span class= + "emphasis"><em>extract</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.patch">14.8. + The <span class="emphasis"><em>patch</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.tools">14.9. + The <span class="emphasis"><em>tools</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.wrapper">14.10. The <span class= + "emphasis"><em>wrapper</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.configure">14.11. The <span class= + "emphasis"><em>configure</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.build">14.12. + The <span class="emphasis"><em>build</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.test">14.13. + The <span class="emphasis"><em>test</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.install">14.14. The <span class= + "emphasis"><em>install</em></span> + phase</a></span></dt> <dt><span class="sect1"><a href= - "#build.helpful-targets">14.3. Other helpful + "#build.package">14.15. The <span class= + "emphasis"><em>package</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.helpful-targets">14.16. Other helpful targets</a></span></dt> </dl> </dd> @@ -7579,7 +7700,7 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> print-PLIST</strong></span> command to output a PLIST that matches any new files since the package was extracted. See <a href="#build.helpful-targets" title= - "14.3. Other helpful targets">Section 14.3, + "14.16. Other helpful targets">Section 14.16, “Other helpful targets”</a> for more information on this target.</p> </div> @@ -9977,30 +10098,110 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> <p><b>Table of Contents</b></p> <dl> - <dt><span class="sect1"><a href="#build.prefix">14.1. + <dt><span class="sect1"><a href="#build.intro">14.1. + Introduction</a></span></dt> + + <dt><span class="sect1"><a href="#build.prefix">14.2. Program location</a></span></dt> - <dt><span class="sect1"><a href="#main-targets">14.2. - Main targets</a></span></dt> + <dt><span class="sect1"><a href= + "#build.builddirs">14.3. Directories used during the + build process</a></span></dt> + + <dt><span class="sect1"><a href="#build.running">14.4. + Running a phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.fetch">14.5. + The <span class="emphasis"><em>fetch</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.checksum">14.6. + The <span class="emphasis"><em>checksum</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.extract">14.7. + The <span class="emphasis"><em>extract</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.patch">14.8. + The <span class="emphasis"><em>patch</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.tools">14.9. + The <span class="emphasis"><em>tools</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.wrapper">14.10. + The <span class="emphasis"><em>wrapper</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href= + "#build.configure">14.11. The <span class= + "emphasis"><em>configure</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.build">14.12. + The <span class="emphasis"><em>build</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.test">14.13. + The <span class="emphasis"><em>test</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.install">14.14. + The <span class="emphasis"><em>install</em></span> + phase</a></span></dt> + + <dt><span class="sect1"><a href="#build.package">14.15. + The <span class="emphasis"><em>package</em></span> + phase</a></span></dt> <dt><span class="sect1"><a href= - "#build.helpful-targets">14.3. Other helpful + "#build.helpful-targets">14.16. Other helpful targets</a></span></dt> </dl> </div> - <p>The basic steps for building a program are always the - same. First the program's source (<span class= - "emphasis"><em>distfile</em></span>) must be brought to the - local system and then extracted. After any patches to - compile properly on NetBSD are applied, the software can be - configured, then built (usually by compiling), and finally - the generated binaries, etc. can be put into place on the - system. These are exactly the steps performed by the NetBSD - package system, which is implemented as a series of targets - in a central Makefile, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">pkgsrc/mk/bsd.pkg.mk</code>.</p> + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.intro" id= + "build.intro"></a>14.1. Introduction</h2> + </div> + </div> + </div> + + <p>This chapter gives a detailed description on how a + package is built. Building a package is separated into + different <span class="emphasis"><em>phases</em></span> + (for example <code class="varname">fetch</code>, + <code class="varname">build</code>, <code class= + "varname">install</code>), all of which are described in + the following sections. Each phase is splitted into + so-called <span class="emphasis"><em>stages</em></span>, + which take the name of the containing stage, prefixed by + one of <code class="varname">pre-</code>, <code class= + "varname">do-</code> or <code class= + "varname">post-</code>. (Examples are <code class= + "varname">pre-configure</code>, <code class= + "varname">post-build</code>.) Most of the actual work is + done in the <code class="varname">do-*</code> stages.</p> + + <p>The basic steps for building a program are always the + same. First the program's source (<span class= + "emphasis"><em>distfile</em></span>) must be brought to + the local system and then extracted. After any patches to + compile properly on NetBSD are applied, the software can + be configured, then built (usually by compiling), and + finally the generated binaries, etc. can be put into + place on the system. These are exactly the steps + performed by the NetBSD package system, which is + implemented as a series of targets in a central Makefile, + <code xmlns="http://www.w3.org/TR/xhtml1/transitional" + class="filename">pkgsrc/mk/bsd.pkg.mk</code>.</p> + </div> <div class="sect1" lang="en" xml:lang="en"> <div class="titlepage"> @@ -10008,7 +10209,7 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> <div> <h2 class="title" style="clear: both"><a name= "build.prefix" id= - "build.prefix"></a>14.1. Program location</h2> + "build.prefix"></a>14.2. Program location</h2> </div> </div> </div> @@ -10193,276 +10394,469 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> <div> <div> <h2 class="title" style="clear: both"><a name= - "main-targets" id= - "main-targets"></a>14.2. Main targets</h2> + "build.builddirs" id= + "build.builddirs"></a>14.3. Directories used + during the build process</h2> </div> </div> </div> - <p>The main targets used during the build process defined - in <code xmlns="http://www.w3.org/TR/xhtml1/transitional" - class="filename">bsd.pkg.mk</code> are:</p> + <p>When building a package, a number of directories is + used to store source files, temporary files, + pkgsrc-internal files, and so on. These directories are + explained here.</p> + + <p>Some of the directory variables contain relative + pathnames. There are two common base directories for + these relative directories: <code class= + "varname">PKGSRCDIR/PKGPATH</code> is used for + directories that are pkgsrc-specific. <code class= + "varname">WRKSRC</code> is used for directories inside + the package itself. The permissions after each variable + indicate whether the variable may be changed by the + package Makefile.</p> <div class="variablelist"> <dl> - <dt><span class="term">fetch</span></dt> + <dt><span class="term"><code class= + "varname">PKGSRCDIR</code> (read-only)</span></dt> <dd> - <p>This will check if the file(s) given in the - variables <code class="varname">DISTFILES</code> - and <code class="varname">PATCHFILES</code> (as - defined in the package's Makefile) are present on - the local system in <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">/usr/pkgsrc/distfiles</code>. If they - are not present, an attempt will be made to fetch - them using commands of the form:</p> - <pre class="programlisting"> - ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} -</pre> + <p>This is an absolute pathname that points to the + pkgsrc root directory. Generally, you don't need + it.</p> + </dd> + + <dt><span class="term"><code class= + "varname">PKGPATH</code> (read-only)</span></dt> - <p>where ${site} varies through several - possibilities in turn: first, <code class= - "varname">MASTER_SITE_OVERRIDE</code> is tried, - then the sites specified in either <code class= - "varname">SITES_file</code> if defined, else - <code class="varname">MASTER_SITES</code> or - <code class="varname">PATCH_SITES</code>, as - applies, then finally the value of <code class= - "varname">MASTER_SITE_BACKUP</code>. The order of - all except the first can be optionally sorted by - the user, via setting either <code class= - "varname">MASTER_SORT_AWK</code> or <code class= - "varname">MASTER_SORT_REGEX</code>.</p> + <dd> + <p>This is a pathname relative to <code class= + "varname">PKGSRCDIR</code> that points to the + current package.</p> </dd> - <dt><span class="term">checksum</span></dt> + <dt><span class="term"><code class= + "varname">WRKDIR</code> (read-only)</span></dt> <dd> - <p>After the distfile(s) are fetched, their - checksum is generated and compared with the - checksums stored in the distinfo file. If the - checksums don't match, the build is aborted. This - is to ensure the same distfile is used for - building, and that the distfile wasn't changed, - e.g. by some malign force, deliberately changed - distfiles on the master distribution site or - network lossage.</p> + <p>This is an absolute pathname pointing to the + directory where all work takes place. This + directory typically contains temporary directories + used by the various pkgsrc frameworks, like + <span class="emphasis"><em>buildlink</em></span> or + the <span class= + "emphasis"><em>wrappers</em></span>.</p> </dd> - <dt><span class="term">extract</span></dt> + <dt><span class="term"><code class= + "varname">WRKSRC</code> (read-write)</span></dt> <dd> - <p>When the distfiles are present on the local - system, they need to be extracted, as they are - usually in the form of some compressed archive - format, most commonly <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tar.gz</code>.</p> + <p>This is an absolute pathname pointing to the + directory where the distfiles are extracted. It is + usually a direct subdirectory of <code class= + "varname">WRKDIR</code>, and often it's the only + directory entry that isn't hidden.</p> + </dd> + </dl> + </div> + </div> - <p>If only some of the distfiles need to be - uncompressed, the files to be uncompressed should - be put into <code class= - "varname">EXTRACT_ONLY</code>.</p> + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.running" id= + "build.running"></a>14.4. Running a phase</h2> + </div> + </div> + </div> - <p>If the distfiles are not in <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tar.gz</code> format, they can be - extracted by setting either <code class= - "varname">EXTRACT_SUFX</code>, or <code class= - "varname">EXTRACT_CMD</code>, <code class= - "varname">EXTRACT_BEFORE_ARGS</code> and - <code class="varname">EXTRACT_AFTER_ARGS</code>. In - the former case, pkgsrc knows how to extract a - number of suffixes (<code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tar.gz</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tgz</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tar.gz2</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tbz</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tar.Z</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.tar</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.shar.gz</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.shar.bz2</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.shar.Z</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.shar</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.Z</code>, <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.bz2</code> and <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.gz</code>; see the definition of the - various <code class="varname">DECOMPRESS_CMD</code> - variables in <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">bsd.pkg.extract.mk</code> for a complete - list). Here's an example on how to use the other - variables for a program that comes with a - compressed shell archive whose name ends in - <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.msg.gz</code>:</p> - <pre class="programlisting"> + <p>You can run a particular phase by typing + <span><strong class="command">make phase</strong></span>, + where <span class="emphasis"><em>phase</em></span> is the + name of the phase. This will automatically run all phases + that are required for this phase. The default phase is + <code class="varname">build</code>, that is, when you run + <span><strong class="command">make</strong></span> + without parameters in a package directory, the package + will be built, but not installed.</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.fetch" id="build.fetch"></a>14.5. The + <span class="emphasis"><em>fetch</em></span> + phase</h2> + </div> + </div> + </div> + + <p>This will check if the file(s) given in the variables + <code class="varname">DISTFILES</code> and <code class= + "varname">PATCHFILES</code> (as defined in the package's + Makefile) are present on the local system in <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">/usr/pkgsrc/distfiles</code>. If they are not + present, an attempt will be made to fetch them using + commands of the form:</p> + <pre class="programlisting"> + ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} +</pre> + + <p>where ${site} varies through several possibilities in + turn: first, <code class= + "varname">MASTER_SITE_OVERRIDE</code> is tried, then the + sites specified in either <code class= + "varname">SITES_file</code> if defined, else <code class= + "varname">MASTER_SITES</code> or <code class= + "varname">PATCH_SITES</code>, as applies, then finally + the value of <code class= + "varname">MASTER_SITE_BACKUP</code>. The order of all + except the first can be optionally sorted by the user, + via setting either <code class= + "varname">MASTER_SORT_AWK</code> or <code class= + "varname">MASTER_SORT_REGEX</code>.</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.checksum" id= + "build.checksum"></a>14.6. The <span class= + "emphasis"><em>checksum</em></span> phase</h2> + </div> + </div> + </div> + + <p>After the distfile(s) are fetched, their checksum is + generated and compared with the checksums stored in the + distinfo file. If the checksums don't match, the build is + aborted. This is to ensure the same distfile is used for + building, and that the distfile wasn't changed, e.g. by + some malign force, deliberately changed distfiles on the + master distribution site or network lossage.</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.extract" id= + "build.extract"></a>14.7. The <span class= + "emphasis"><em>extract</em></span> phase</h2> + </div> + </div> + </div> + + <p>When the distfiles are present on the local system, + they need to be extracted, as they are usually in the + form of some compressed archive format, most commonly + <code xmlns="http://www.w3.org/TR/xhtml1/transitional" + class="filename">.tar.gz</code>.</p> + + <p>If only some of the distfiles need to be uncompressed, + the files to be uncompressed should be put into + <code class="varname">EXTRACT_ONLY</code>.</p> + + <p>If the distfiles are not in <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.tar.gz</code> format, they can be extracted + by setting either <code class= + "varname">EXTRACT_SUFX</code>, or <code class= + "varname">EXTRACT_CMD</code>, <code class= + "varname">EXTRACT_BEFORE_ARGS</code> and <code class= + "varname">EXTRACT_AFTER_ARGS</code>. In the former case, + pkgsrc knows how to extract a number of suffixes + (<code xmlns="http://www.w3.org/TR/xhtml1/transitional" + class="filename">.tar.gz</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.tgz</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.tar.gz2</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.tbz</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.tar.Z</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.tar</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.shar.gz</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.shar.bz2</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.shar.Z</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.shar</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.Z</code>, <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.bz2</code> and <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.gz</code>; see the definition of the various + <code class="varname">DECOMPRESS_CMD</code> variables in + <code xmlns="http://www.w3.org/TR/xhtml1/transitional" + class="filename">bsd.pkg.extract.mk</code> for a complete + list). Here's an example on how to use the other + variables for a program that comes with a compressed + shell archive whose name ends in <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.msg.gz</code>:</p> + <pre class="programlisting"> EXTRACT_SUFX= .msg.gz EXTRACT_CMD= zcat EXTRACT_BEFORE_ARGS= EXTRACT_AFTER_ARGS= |sh </pre> - </dd> + </div> - <dt><span class="term">patch</span></dt> + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.patch" id="build.patch"></a>14.8. The + <span class="emphasis"><em>patch</em></span> + phase</h2> + </div> + </div> + </div> - <dd> - <p>After extraction, all the patches named by the - <code class="varname">PATCHFILES</code>, those - present in the patches subdirectory of the package - as well as in $LOCALPATCHES/$PKGPATH (e.g. - <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">/usr/local/patches/graphics/png</code>) - are applied. Patchfiles ending in <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.Z</code> or <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.gz</code> are uncompressed before they - are applied, files ending in <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.orig</code> or <code xmlns= - "http://www.w3.org/TR/xhtml1/transitional" class= - "filename">.rej</code> are ignored. Any special - options to <a href= - "http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current"> - <span class="citerefentry"><span class= - "refentrytitle">patch</span>(1)</span></a> can be - handed in <code class= - "varname">PATCH_DIST_ARGS</code>. See <a href= - "#components.patches" title= - "8.3. patches/*">Section 8.3, - “patches/*”</a> for more details.</p> + <p>After extraction, all the patches named by the + <code class="varname">PATCHFILES</code>, those present in + the patches subdirectory of the package as well as in + $LOCALPATCHES/$PKGPATH (e.g. <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">/usr/local/patches/graphics/png</code>) are + applied. Patchfiles ending in <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.Z</code> or <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.gz</code> are uncompressed before they are + applied, files ending in <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.orig</code> or <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">.rej</code> are ignored. Any special options + to <a href= + "http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current"> + <span class="citerefentry"><span class= + "refentrytitle">patch</span>(1)</span></a> can be handed + in <code class="varname">PATCH_DIST_ARGS</code>. See + <a href="#components.patches" title= + "8.3. patches/*">Section 8.3, + “patches/*”</a> for more details.</p> - <p>By default <a href= - "http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current"> - <span class="citerefentry"><span class= - "refentrytitle">patch</span>(1)</span></a> is given - special args to make it fail if the patches apply - with some lines of fuzz. Please fix (regen) the - patches so that they apply cleanly. The rationale - behind this is that patches that don't apply - cleanly may end up being applied in the wrong - place, and cause severe harm there.</p> - </dd> + <p>By default <a href= + "http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current"> + <span class="citerefentry"><span class= + "refentrytitle">patch</span>(1)</span></a> is given + special args to make it fail if the patches apply with + some lines of fuzz. Please fix (regen) the patches so + that they apply cleanly. The rationale behind this is + that patches that don't apply cleanly may end up being + applied in the wrong place, and cause severe harm + there.</p> + </div> - <dt><span class="term">configure</span></dt> + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.tools" id="build.tools"></a>14.9. The + <span class="emphasis"><em>tools</em></span> + phase</h2> + </div> + </div> + </div> - <dd> - <p>Most pieces of software need information on the - header files, system calls, and library routines - which are available in NetBSD. This is the process - known as configuration, and is usually automated. - In most cases, a script is supplied with the - source, and its invocation results in generation of - header files, Makefiles, etc.</p> - - <p>If the program's distfile contains its own - configure script, this can be invoked by setting - <code class="varname">HAS_CONFIGURE</code>. If the - configure script is a GNU autoconf script, - <code class="varname">GNU_CONFIGURE</code> should - be specified instead. In either case, any arguments - to the configure script can be specified in the - <code class="varname">CONFIGURE_ARGS</code> - variable, and the configure script's name can be - set in <code class= - "varname">CONFIGURE_SCRIPT</code> if it differs - from the default “<span class= - "quote">configure</span>”. Here's an example - from the <a xmlns= - "http://www.w3.org/TR/xhtml1/transitional" href= - "ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/sysutils/top/README.html" - target="_top"><code xmlns="" class= - "filename">sysutils/top</code></a> package:</p> - <pre class="programlisting"> - HAS_CONFIGURE= yes - CONFIGURE_SCRIPT= Configure - CONFIGURE_ARGS+= netbsd13 -</pre> - - <p>If the program uses an Imakefile for - configuration, the appropriate steps can be invoked - by setting <code class="varname">USE_IMAKE</code> - to “<span class="quote">YES</span>”. - (If you only want the package installed in - <code class="varname">$X11PREFIX</code> but xmkmf - not being run, set <code class= - "varname">USE_X11BASE</code> instead!)</p> - </dd> + <p>[TODO]</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.wrapper" id= + "build.wrapper"></a>14.10. The <span class= + "emphasis"><em>wrapper</em></span> phase</h2> + </div> + </div> + </div> - <dt><span class="term">build</span></dt> + <p>[TODO]</p> + </div> - <dd> - <p>Once configuration has taken place, the software - will be built by invoking <code class= - "varname">$MAKE_PROGRAM</code> on <code class= - "varname">$MAKEFILE</code> with <code class= - "varname">$BUILD_TARGET</code> as the target to - build. The default <code class= - "varname">MAKE_PROGRAM</code> is - “<span class="quote">gmake</span>” if - <code class="varname">USE_TOOLS</code> contains - “<span class="quote">gmake</span>”, - “<span class="quote">make</span>” - otherwise. <code class="varname">MAKEFILE</code> is - set to “<span class= - "quote">Makefile</span>” by default, and - <code class="varname">BUILD_TARGET</code> defaults - to “<span class="quote">all</span>”. - Any of these variables can be set in the package's - Makefile to change the default build process.</p> - </dd> + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.configure" id= + "build.configure"></a>14.11. The <span class= + "emphasis"><em>configure</em></span> phase</h2> + </div> + </div> + </div> + + <p>Most pieces of software need information on the header + files, system calls, and library routines which are + available on the platform they run on. The process of + determining this information is known as configuration, + and is usually automated. In most cases, a script is + supplied with the distfiles, and its invocation results + in generation of header files, Makefiles, etc.</p> + + <p>If the package contains a configure script, this can + be invoked by setting <code class= + "varname">HAS_CONFIGURE</code> to “<span class= + "quote">yes</span>”. If the configure script is a + GNU autoconf script, you should set <code class= + "varname">GNU_CONFIGURE</code> to “<span class= + "quote">yes</span>” instead. What happens in the + <span class="emphasis"><em>configure</em></span> phase is + roughly:</p> + <pre class="programlisting"> + .for d in ${CONFIGURE_DIRS} + cd ${WRKSRC} && cd ${d} && env ${CONFIGURE_ENV} \ + ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS} + .endfor +</pre> - <dt><span class="term">install</span></dt> + <p><code class="varname">CONFIGURE_DIRS</code> (default: + “<span class="quote">.</span>”) is a list of + pathnames relative to <code class= + "varname">WRKSRC</code>. In each of these directories, + the configure script is run with the environment + <code class="varname">CONFIGURE_ENV</code> and arguments + <code class="varname">CONFIGURE_ARGS</code>. The + variables <code class="varname">CONFIGURE_ENV</code>, + <code class="varname">CONFIGURE_SCRIPT</code> (default: + “<span class="quote">./configure</span>”) and + <code class="varname">CONFIGURE_ARGS</code> may all be + changed by the package.</p> + + <p>If the program uses an <code xmlns= + "http://www.w3.org/TR/xhtml1/transitional" class= + "filename">Imakefile</code> for configuration, the + appropriate steps can be invoked by setting <code class= + "varname">USE_IMAKE</code> to “<span class= + "quote">yes</span>”. (If you only want the package + installed in <code class="varname">${X11PREFIX}</code> + but xmkmf not being run, set <code class= + "varname">USE_X11BASE</code> instead.)</p> + </div> - <dd> - <p>Once the build stage has completed, the final - step is to install the software in public - directories, so users can access the programs and - files. As in the build-target, <code class= - "varname">$MAKE_PROGRAM</code> is invoked on - <code class="varname">$MAKEFILE</code> here, but - with the <code class= - "varname">$INSTALL_TARGET</code> instead, the - latter defaulting to “<span class= - "quote">install</span>” (plus - “<span class= - "quote">install.man</span>”, if <code class= - "varname">USE_IMAKE</code> is set).</p> - </dd> - </dl> + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.build" id="build.build"></a>14.12. The + <span class="emphasis"><em>build</em></span> + phase</h2> + </div> + </div> </div> - <p>If no target is specified, the default is - “<span class="quote">build</span>”. If a - subsequent stage is requested, all prior stages are made: - e.g. <span><strong class="command">make - build</strong></span> will also perform the equivalent - of:</p> + <p>For building a package, a rough equivalent of the + following code is executed.</p> <pre class="programlisting"> - make fetch - make checksum - make extract - make patch - make configure - make build + .for d in ${BUILD_DIRS} + cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ + ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ + -f ${MAKEFILE} ${BUILD_TARGET} + .endfor </pre> + + <p><code class="varname">BUILD_DIRS</code> (default: + “<span class="quote">.</span>”) is a list of + pathnames relative to <code class= + "varname">WRKSRC</code>. In each of these directories, + <code class="varname">MAKE_PROGRAM</code> is run with the + environment <code class="varname">MAKE_ENV</code> and + arguments <code class="varname">BUILD_MAKE_FLAGS</code>. + The variables <code class="varname">MAKE_ENV</code>, + <code class="varname">BUILD_MAKE_FLAGS</code>, + <code class="varname">MAKEFILE</code> and <code class= + "varname">BUILD_TARGET</code> may all be changed by the + package.</p> + + <p>The default value of <code class= + "varname">MAKE_PROGRAM</code> is “<span class= + "quote">gmake</span>” if <code class= + "varname">USE_TOOLS</code> contains “<span class= + "quote">gmake</span>”, “<span class= + "quote">make</span>” otherwise. The default value + of <code class="varname">MAKEFILE</code> is + “<span class="quote">Makefile</span>”, and + <code class="varname">BUILD_TARGET</code> defaults to + “<span class="quote">all</span>”.</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.test" id="build.test"></a>14.13. The + <span class="emphasis"><em>test</em></span> + phase</h2> + </div> + </div> + </div> + + <p>[TODO]</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.install" id= + "build.install"></a>14.14. The <span class= + "emphasis"><em>install</em></span> phase</h2> + </div> + </div> + </div> + + <p>Once the build stage has completed, the final step is + to install the software in public directories, so users + can access the programs and files. As in the + build-target, <code class="varname">$MAKE_PROGRAM</code> + is invoked on <code class="varname">$MAKEFILE</code> + here, but with the <code class= + "varname">$INSTALL_TARGET</code> instead, the latter + defaulting to “<span class= + "quote">install</span>” (plus “<span class= + "quote">install.man</span>”, if <code class= + "varname">USE_IMAKE</code> is set).</p> + </div> + + <div class="sect1" lang="en" xml:lang="en"> + <div class="titlepage"> + <div> + <div> + <h2 class="title" style="clear: both"><a name= + "build.package" id= + "build.package"></a>14.15. The <span class= + "emphasis"><em>package</em></span> phase</h2> + </div> + </div> + </div> + + <p>[TODO]</p> </div> <div class="sect1" lang="en" xml:lang="en"> @@ -10471,7 +10865,7 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> <div> <h2 class="title" style="clear: both"><a name= "build.helpful-targets" id= - "build.helpful-targets"></a>14.3. Other + "build.helpful-targets"></a>14.16. Other helpful targets</h2> </div> </div> @@ -12485,6 +12879,7 @@ nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> also use the following defines.</p> <pre class="programlisting"> FreeBSD __FreeBSD__ + DragonFly __DragonFly__ Linux linux, __linux, __linux__ NetBSD __NetBSD__ OpenBSD __OpenBSD__ diff --git a/doc/pkgsrc.txt b/doc/pkgsrc.txt index 6da7d985a3e..e4db8ad15fb 100644 --- a/doc/pkgsrc.txt +++ b/doc/pkgsrc.txt @@ -195,9 +195,22 @@ II. The pkgsrc developer's guide 14. The build process - 14.1. Program location - 14.2. Main targets - 14.3. Other helpful targets + 14.1. Introduction + 14.2. Program location + 14.3. Directories used during the build process + 14.4. Running a phase + 14.5. The fetch phase + 14.6. The checksum phase + 14.7. The extract phase + 14.8. The patch phase + 14.9. The tools phase + 14.10. The wrapper phase + 14.11. The configure phase + 14.12. The build phase + 14.13. The test phase + 14.14. The install phase + 14.15. The package phase + 14.16. Other helpful targets 15. Making your package work @@ -1437,7 +1450,7 @@ a binary package. 6.2. Settings for creation of binary packages -See Section 14.3, "Other helpful targets". +See Section 14.16, "Other helpful targets". 6.3. Doing a bulk build of all packages @@ -2188,9 +2201,22 @@ Table of Contents 14. The build process - 14.1. Program location - 14.2. Main targets - 14.3. Other helpful targets + 14.1. Introduction + 14.2. Program location + 14.3. Directories used during the build process + 14.4. Running a phase + 14.5. The fetch phase + 14.6. The checksum phase + 14.7. The extract phase + 14.8. The patch phase + 14.9. The tools phase + 14.10. The wrapper phase + 14.11. The configure phase + 14.12. The build phase + 14.13. The test phase + 14.14. The install phase + 14.15. The package phase + 14.16. Other helpful targets 15. Making your package work @@ -2819,7 +2845,7 @@ Be sure to add a RCS ID line as the first thing in any PLIST file you write: 10.2. Semi-automatic PLIST generation You can use the make print-PLIST command to output a PLIST that matches any new -files since the package was extracted. See Section 14.3, "Other helpful +files since the package was extracted. See Section 14.16, "Other helpful targets" for more information on this target. 10.3. Tweaking output of make print-PLIST @@ -3776,9 +3802,31 @@ Chapter 14. The build process Table of Contents -14.1. Program location -14.2. Main targets -14.3. Other helpful targets +14.1. Introduction +14.2. Program location +14.3. Directories used during the build process +14.4. Running a phase +14.5. The fetch phase +14.6. The checksum phase +14.7. The extract phase +14.8. The patch phase +14.9. The tools phase +14.10. The wrapper phase +14.11. The configure phase +14.12. The build phase +14.13. The test phase +14.14. The install phase +14.15. The package phase +14.16. Other helpful targets + +14.1. Introduction + +This chapter gives a detailed description on how a package is built. Building a +package is separated into different phases (for example fetch, build, install), +all of which are described in the following sections. Each phase is splitted +into so-called stages, which take the name of the containing stage, prefixed by +one of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of +the actual work is done in the do-* stages. The basic steps for building a program are always the same. First the program's source (distfile) must be brought to the local system and then extracted. After @@ -3788,7 +3836,7 @@ binaries, etc. can be put into place on the system. These are exactly the steps performed by the NetBSD package system, which is implemented as a series of targets in a central Makefile, pkgsrc/mk/bsd.pkg.mk. -14.1. Program location +14.2. Program location Before outlining the process performed by the NetBSD package system in the next section, here's a brief discussion on where programs are installed, and which @@ -3863,126 +3911,180 @@ When choosing which of these variables to use, follow the following rules: the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/ man. -14.2. Main targets +14.3. Directories used during the build process -The main targets used during the build process defined in bsd.pkg.mk are: - -fetch - - This will check if the file(s) given in the variables DISTFILES and - PATCHFILES (as defined in the package's Makefile) are present on the local - system in /usr/pkgsrc/distfiles. If they are not present, an attempt will - be made to fetch them using commands of the form: - - ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} - - where ${site} varies through several possibilities in turn: first, - MASTER_SITE_OVERRIDE is tried, then the sites specified in either - SITES_file if defined, else MASTER_SITES or PATCH_SITES, as applies, then - finally the value of MASTER_SITE_BACKUP. The order of all except the first - can be optionally sorted by the user, via setting either MASTER_SORT_AWK or - MASTER_SORT_REGEX. - -checksum - - After the distfile(s) are fetched, their checksum is generated and compared - with the checksums stored in the distinfo file. If the checksums don't - match, the build is aborted. This is to ensure the same distfile is used - for building, and that the distfile wasn't changed, e.g. by some malign - force, deliberately changed distfiles on the master distribution site or - network lossage. - -extract - - When the distfiles are present on the local system, they need to be - extracted, as they are usually in the form of some compressed archive - format, most commonly .tar.gz. - - If only some of the distfiles need to be uncompressed, the files to be - uncompressed should be put into EXTRACT_ONLY. - - If the distfiles are not in .tar.gz format, they can be extracted by - setting either EXTRACT_SUFX, or EXTRACT_CMD, EXTRACT_BEFORE_ARGS and - EXTRACT_AFTER_ARGS. In the former case, pkgsrc knows how to extract a - number of suffixes (.tar.gz, .tgz, .tar.gz2, .tbz, .tar.Z, .tar, .shar.gz, - .shar.bz2, .shar.Z, .shar, .Z, .bz2 and .gz; see the definition of the - various DECOMPRESS_CMD variables in bsd.pkg.extract.mk for a complete - list). Here's an example on how to use the other variables for a program - that comes with a compressed shell archive whose name ends in .msg.gz: - - EXTRACT_SUFX= .msg.gz - EXTRACT_CMD= zcat - EXTRACT_BEFORE_ARGS= - EXTRACT_AFTER_ARGS= |sh - -patch - - After extraction, all the patches named by the PATCHFILES, those present in - the patches subdirectory of the package as well as in $LOCALPATCHES/ - $PKGPATH (e.g. /usr/local/patches/graphics/png) are applied. Patchfiles - ending in .Z or .gz are uncompressed before they are applied, files ending - in .orig or .rej are ignored. Any special options to patch(1) can be handed - in PATCH_DIST_ARGS. See Section 8.3, "patches/*" for more details. - - By default patch(1) is given special args to make it fail if the patches - apply with some lines of fuzz. Please fix (regen) the patches so that they - apply cleanly. The rationale behind this is that patches that don't apply - cleanly may end up being applied in the wrong place, and cause severe harm - there. - -configure - - Most pieces of software need information on the header files, system calls, - and library routines which are available in NetBSD. This is the process - known as configuration, and is usually automated. In most cases, a script - is supplied with the source, and its invocation results in generation of - header files, Makefiles, etc. - - If the program's distfile contains its own configure script, this can be - invoked by setting HAS_CONFIGURE. If the configure script is a GNU autoconf - script, GNU_CONFIGURE should be specified instead. In either case, any - arguments to the configure script can be specified in the CONFIGURE_ARGS - variable, and the configure script's name can be set in CONFIGURE_SCRIPT if - it differs from the default "configure". Here's an example from the - sysutils/top package: - - HAS_CONFIGURE= yes - CONFIGURE_SCRIPT= Configure - CONFIGURE_ARGS+= netbsd13 - - If the program uses an Imakefile for configuration, the appropriate steps - can be invoked by setting USE_IMAKE to "YES". (If you only want the package - installed in $X11PREFIX but xmkmf not being run, set USE_X11BASE instead!) - -build - - Once configuration has taken place, the software will be built by invoking - $MAKE_PROGRAM on $MAKEFILE with $BUILD_TARGET as the target to build. The - default MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "make" - otherwise. MAKEFILE is set to "Makefile" by default, and BUILD_TARGET - defaults to "all". Any of these variables can be set in the package's - Makefile to change the default build process. - -install - - Once the build stage has completed, the final step is to install the - software in public directories, so users can access the programs and files. - As in the build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but - with the $INSTALL_TARGET instead, the latter defaulting to "install" (plus - "install.man", if USE_IMAKE is set). - -If no target is specified, the default is "build". If a subsequent stage is -requested, all prior stages are made: e.g. make build will also perform the -equivalent of: - - make fetch - make checksum - make extract - make patch - make configure - make build - -14.3. Other helpful targets +When building a package, a number of directories is used to store source files, +temporary files, pkgsrc-internal files, and so on. These directories are +explained here. + +Some of the directory variables contain relative pathnames. There are two +common base directories for these relative directories: PKGSRCDIR/PKGPATH is +used for directories that are pkgsrc-specific. WRKSRC is used for directories +inside the package itself. The permissions after each variable indicate whether +the variable may be changed by the package Makefile. + +PKGSRCDIR (read-only) + + This is an absolute pathname that points to the pkgsrc root directory. + Generally, you don't need it. + +PKGPATH (read-only) + + This is a pathname relative to PKGSRCDIR that points to the current + package. + +WRKDIR (read-only) + + This is an absolute pathname pointing to the directory where all work takes + place. This directory typically contains temporary directories used by the + various pkgsrc frameworks, like buildlink or the wrappers. + +WRKSRC (read-write) + + This is an absolute pathname pointing to the directory where the distfiles + are extracted. It is usually a direct subdirectory of WRKDIR, and often + it's the only directory entry that isn't hidden. + +14.4. Running a phase + +You can run a particular phase by typing make phase, where phase is the name of +the phase. This will automatically run all phases that are required for this +phase. The default phase is build, that is, when you run make without +parameters in a package directory, the package will be built, but not +installed. + +14.5. The fetch phase + +This will check if the file(s) given in the variables DISTFILES and PATCHFILES +(as defined in the package's Makefile) are present on the local system in /usr/ +pkgsrc/distfiles. If they are not present, an attempt will be made to fetch +them using commands of the form: + + ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} + +where ${site} varies through several possibilities in turn: first, +MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES_file if +defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value +of MASTER_SITE_BACKUP. The order of all except the first can be optionally +sorted by the user, via setting either MASTER_SORT_AWK or MASTER_SORT_REGEX. + +14.6. The checksum phase + +After the distfile(s) are fetched, their checksum is generated and compared +with the checksums stored in the distinfo file. If the checksums don't match, +the build is aborted. This is to ensure the same distfile is used for building, +and that the distfile wasn't changed, e.g. by some malign force, deliberately +changed distfiles on the master distribution site or network lossage. + +14.7. The extract phase + +When the distfiles are present on the local system, they need to be extracted, +as they are usually in the form of some compressed archive format, most +commonly .tar.gz. + +If only some of the distfiles need to be uncompressed, the files to be +uncompressed should be put into EXTRACT_ONLY. + +If the distfiles are not in .tar.gz format, they can be extracted by setting +either EXTRACT_SUFX, or EXTRACT_CMD, EXTRACT_BEFORE_ARGS and +EXTRACT_AFTER_ARGS. In the former case, pkgsrc knows how to extract a number of +suffixes (.tar.gz, .tgz, .tar.gz2, .tbz, .tar.Z, .tar, .shar.gz, .shar.bz2, +.shar.Z, .shar, .Z, .bz2 and .gz; see the definition of the various +DECOMPRESS_CMD variables in bsd.pkg.extract.mk for a complete list). Here's an +example on how to use the other variables for a program that comes with a +compressed shell archive whose name ends in .msg.gz: + + EXTRACT_SUFX= .msg.gz + EXTRACT_CMD= zcat + EXTRACT_BEFORE_ARGS= + EXTRACT_AFTER_ARGS= |sh + +14.8. The patch phase + +After extraction, all the patches named by the PATCHFILES, those present in the +patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g. +/usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz +are uncompressed before they are applied, files ending in .orig or .rej are +ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See +Section 8.3, "patches/*" for more details. + +By default patch(1) is given special args to make it fail if the patches apply +with some lines of fuzz. Please fix (regen) the patches so that they apply +cleanly. The rationale behind this is that patches that don't apply cleanly may +end up being applied in the wrong place, and cause severe harm there. + +14.9. The tools phase + +[TODO] + +14.10. The wrapper phase + +[TODO] + +14.11. The configure phase + +Most pieces of software need information on the header files, system calls, and +library routines which are available on the platform they run on. The process +of determining this information is known as configuration, and is usually +automated. In most cases, a script is supplied with the distfiles, and its +invocation results in generation of header files, Makefiles, etc. + +If the package contains a configure script, this can be invoked by setting +HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you +should set GNU_CONFIGURE to "yes" instead. What happens in the configure phase +is roughly: + + .for d in ${CONFIGURE_DIRS} + cd ${WRKSRC} && cd ${d} && env ${CONFIGURE_ENV} \ + ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS} + .endfor + +CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In +each of these directories, the configure script is run with the environment +CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV, +CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed +by the package. + +If the program uses an Imakefile for configuration, the appropriate steps can +be invoked by setting USE_IMAKE to "yes". (If you only want the package +installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.) + +14.12. The build phase + +For building a package, a rough equivalent of the following code is executed. + + .for d in ${BUILD_DIRS} + cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ + ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ + -f ${MAKEFILE} ${BUILD_TARGET} + .endfor + +BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of +these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and +arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKEFILE +and BUILD_TARGET may all be changed by the package. + +The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", +"make" otherwise. The default value of MAKEFILE is "Makefile", and BUILD_TARGET +defaults to "all". + +14.13. The test phase + +[TODO] + +14.14. The install phase + +Once the build stage has completed, the final step is to install the software +in public directories, so users can access the programs and files. As in the +build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with the +$INSTALL_TARGET instead, the latter defaulting to "install" (plus +"install.man", if USE_IMAKE is set). + +14.15. The package phase + +[TODO] + +14.16. Other helpful targets pre/post-* @@ -4817,6 +4919,7 @@ should use the following code. If this distinction is not fine enough, you can also use the following defines. FreeBSD __FreeBSD__ + DragonFly __DragonFly__ Linux linux, __linux, __linux__ NetBSD __NetBSD__ OpenBSD __OpenBSD__ |