From owner-svn-doc-head@FreeBSD.ORG Tue Sep 16 20:12:18 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A31F776; Tue, 16 Sep 2014 20:12:18 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83B856C7; Tue, 16 Sep 2014 20:12:18 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id s8GKCIIS063737; Tue, 16 Sep 2014 20:12:18 GMT (envelope-from mat@FreeBSD.org) Received: (from mat@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id s8GKCIBo063736; Tue, 16 Sep 2014 20:12:18 GMT (envelope-from mat@FreeBSD.org) Message-Id: <201409162012.s8GKCIBo063736@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: mat set sender to mat@FreeBSD.org using -f From: Mathieu Arnold Date: Tue, 16 Sep 2014 20:12:18 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r45627 - head/en_US.ISO8859-1/books/porters-handbook/makefiles X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:12:18 -0000 Author: mat (ports committer) Date: Tue Sep 16 20:12:18 2014 New Revision: 45627 URL: http://svnweb.freebsd.org/changeset/doc/45627 Log: igor -Ry and some other rewording and fixes. Differential Revision: https://reviews.freebsd.org/D643 Reviewed by: wblock Sponsored by: Absolight Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Tue Sep 16 19:29:22 2014 (r45626) +++ head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Tue Sep 16 20:12:18 2014 (r45627) @@ -11,35 +11,34 @@ Configuring the Makefile Configuring the Makefile is pretty - simple, and again we suggest that you look at existing examples + simple, and again we suggest looking at existing examples before starting. Also, there is a sample Makefile in this handbook, so take a look and please follow the ordering of - variables and sections in that template to make your port easier + variables and sections in that template to make the port easier for others to read. - Now, consider the following problems in sequence as you - design your new Makefile: + Consider these problems in sequence during the + design of the new Makefile: The Original Source Does it live in DISTDIR as a standard gzipped tarball named something like - foozolix-1.2.tar.gz? If so, you can go on - to the next step. If not, you should look at overriding any of - the DISTVERSION, DISTNAME, + foozolix-1.2.tar.gz? If so, go on + to the next step. If not, the distribution file format might + require overriding one or more of + DISTVERSION, DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, - EXTRACT_SUFX, or DISTFILES - variables, depending on how alien a format your port's - distribution file is. + EXTRACT_SUFX, or + DISTFILES. - In the worst case, you can simply create your own + In the worst case, create a custom do-extract target to override the - default, though this should be rarely, if ever, - necessary. + default. This is rarely, if ever, necessary. @@ -53,17 +52,17 @@ <varname>PORTNAME</varname> and <varname>PORTVERSION</varname> - You should set PORTNAME to the base - name of your port, and PORTVERSION to the + Set PORTNAME to the base + name of the port, and PORTVERSION to the version number of the port. - - Package name should be unique among all of the ports - tree, check that there is not already a port with the same + + The package name must be unique among all of the ports + tree. Make sure that there is not already a port with the same PORTNAME and if there is add one of PKGNAMEPREFIX or PKGNAMESUFFIX. - + @@ -73,24 +72,24 @@ <varname>PORTREVISION</varname> - The PORTREVISION variable is a + PORTREVISION is a monotonically increasing value which is reset to 0 with - every increase of PORTVERSION (i.e., - every time a new official vendor release is made), and - appended to the package name if non-zero. Changes to + every increase of PORTVERSION, typically + every time there is a new official vendor release. If + PORTREVISION is non-zero, the value is + appended to the package name. Changes to PORTREVISION are used by automated tools - (e.g., pkg version, see - &man.pkg-version.8;) to highlight the fact that a new - package is available. + like &man.pkg-version.8; to determine that a new package is + available. - PORTREVISION should be increased each + PORTREVISION must be increased each time a change is made to the port that changes the generated package in any way. That includes changes that only affect a package built with non-default options. Examples of when PORTREVISION - should be bumped: + must be bumped: @@ -107,9 +106,9 @@ Changes in the packing list or the install-time - behavior of the package (e.g., change to a script which - generates initial data for the package, like ssh host - keys). + behavior of the package. For example, a change to a script which + generates initial data for the package, like &man.ssh.1; host + keys. @@ -122,7 +121,7 @@ Silent changes to the port distfile which have - significant functional differences, i.e., changes to the + significant functional differences. For example, changes to the distfile requiring a correction to distinfo with no corresponding change to PORTVERSION, where a @@ -150,30 +149,39 @@ Trivial patches to the distfile such as correction of typos, which are not important enough that users of - the package should go to the trouble of + the package have to go to the trouble of upgrading. Build fixes which cause a package to become - compilable where it was previously failing (as long as + compilable where it was previously failing. As long as the changes do not introduce any functional change on any other platforms on which the port did previously - build). Since PORTREVISION reflects + build. Since PORTREVISION reflects the content of the package, if the package was not previously buildable then there is no need to increase PORTREVISION to mark a change. - A rule of thumb is to ask yourself whether a change - committed to a port is something which everyone would - benefit from having (either because of an enhancement, fix, + A rule of thumb is to decide whether a change + committed to a port is something which some people would + benefit from having. Either because of an enhancement, fix, or by virtue that the new package will actually work at - all), and weigh that against that fact that it will cause + all. Then weigh that against that fact that it will cause everyone who regularly updates their ports tree to be - compelled to update. If yes, the - PORTREVISION should be bumped. + compelled to update. If yes, + PORTREVISION must be bumped. + + + People using binary packages will + never see the update if + PORTREVISION is not bumped. Without + increasing PORTREVISION, the + package builders have no way to detect the change and + thus, will not rebuild the package. + @@ -194,38 +202,38 @@ two version number strings. For example: &prompt.user; pkg version -t 0.031 0.29 -> + > The > output indicates that version 0.031 is considered greater than version 0.29, which may not have been obvious to the porter. - In situations such as this, the - PORTEPOCH version should be increased. + In situations such as this, + PORTEPOCH must be increased. If PORTEPOCH is nonzero it is appended to the package name as described in section 0 above. PORTEPOCH must never be decreased or reset to zero, because that would cause comparison to a - package from an earlier epoch to fail (i.e., the package - would not be detected as out of date): the new version - number (e.g., 1.0,1 in the above example) - is still numerically less than the previous version - (20000801), but the ,1 suffix is treated + package from an earlier epoch to fail. For example, the package + would not be detected as out of date. The new version + number, 1.0,1 in the above + example, is still numerically less than the previous version, + 20000801, but the ,1 suffix is treated specially by automated tools and found to be greater than the implied suffix ,0 on the earlier package. Dropping or resetting PORTEPOCH - incorrectly leads to no end of grief; if you do not - understand the above discussion, please keep after it until - you do, or ask questions on the mailing lists. + incorrectly leads to no end of grief. If the discussion + above was not clear enough, please consult the + &a.ports;. It is expected that PORTEPOCH will not be used for the majority of ports, and that sensible use of PORTVERSION can often preempt it becoming necessary if a future release of the software - should change the version structure. However, care is + changes the version structure. However, care is needed by &os; porters when a vendor release is made without an official version number — such as a code snapshot release. The temptation is to label @@ -234,11 +242,14 @@ release is made. For example, if a snapshot release is made on the date - 20000917, and the previous version of the software was - version 1.2, the snapshot release should be given a - PORTVERSION of 1.2.20000917 or similar, - not 20000917, so that the succeeding release, say 1.3, is - still a numerically greater value. + 20000917, and the previous version of the software was + version 1.2, do not use + 20000917 for + PORTVERSION. The correct way is a + PORTVERSION of + 1.2.20000917, or similar, so that the + succeeding release, say 1.3, is still a + numerically greater value. @@ -250,7 +261,7 @@ collection: PORTNAME= gtkmumble -PORTVERSION= 0.10 + PORTVERSION= 0.10 PKGNAME becomes gtkmumble-0.10. @@ -260,8 +271,8 @@ PORTVERSION= 0.10 accordingly. PORTNAME= gtkmumble -PORTVERSION= 0.10 -PORTREVISION= 1 + PORTVERSION= 0.10 + PORTREVISION= 1 PKGNAME becomes gtkmumble-0.10_1 @@ -270,9 +281,9 @@ PORTREVISION= 1 0.2 (it turns out the author actually intended 0.10 to actually mean 0.1.0, not what comes after - 0.9 - oops, too late now). Since the new minor + 0.9 - oops, too late now). Since the new minor version 2 is numerically less than the - previous version 10, the + previous version 10, PORTEPOCH must be bumped to manually force the new package to be detected as newer. Since it is a new vendor release of @@ -280,8 +291,8 @@ PORTREVISION= 1 removed from the Makefile). PORTNAME= gtkmumble -PORTVERSION= 0.2 -PORTEPOCH= 1 + PORTVERSION= 0.2 + PORTEPOCH= 1 PKGNAME becomes gtkmumble-0.2,1 @@ -291,8 +302,8 @@ PORTEPOCH= 1 variables are now: PORTNAME= gtkmumble -PORTVERSION= 0.3 -PORTEPOCH= 1 + PORTVERSION= 0.3 + PORTEPOCH= 1 PKGNAME becomes gtkmumble-0.3,1 @@ -321,9 +332,10 @@ PORTEPOCH= 1 ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Make sure this conforms to our guidelines for a good - package name. In particular, you are - not allowed to use a hyphen - (-) in PORTVERSION. + package name. In particular, the use of a + hyphen (-) in + PORTVERSION is not + allowed. Also, if the package name has the language- or the -compiled.specifics part (see @@ -370,8 +382,7 @@ PORTEPOCH= 1 French. The language- part is - set in the PKGNAMEPREFIX - variable. + set in PKGNAMEPREFIX. @@ -379,34 +390,30 @@ PORTEPOCH= 1 name - The first letter of the name - part should be lowercase. (The rest of the name may - contain capital letters, so use your own discretion when - converting a software name that has some capital letters - in it.) There is a tradition of naming - Perl 5 modules by prepending - p5- and converting the double-colon - separator to a hyphen. For example, the - Data::Dumper module becomes - p5-Data-Dumper. - Make sure that the port's name and version are - clearly separated and placed into the + clearly separated and placed into PORTNAME and - PORTVERSION variables. The only + PORTVERSION. The only reason for PORTNAME to contain a version part is if the upstream distribution is really named that way, as in the - textproc/libxml2 or - japanese/kinput2-freewnn ports. - Otherwise, the PORTNAME should not + textproc/libxml2 or + japanese/kinput2-freewnn ports. + Otherwise, PORTNAME cannot contain any version-specific information. It is quite normal for several ports to have the same PORTNAME, as the - www/apache* ports do; in that case, + www/apache* ports do; in that case, different versions (and different index entries) are - distinguished by the PKGNAMEPREFIX + distinguished by PKGNAMEPREFIX and PKGNAMESUFFIX values. + + There is a tradition of naming + Perl 5 modules by prepending + p5- and converting the double-colon + separator to a hyphen. For example, the + Data::Dumper module becomes + p5-Data-Dumper. @@ -419,13 +426,12 @@ PORTEPOCH= 1 (usually part of the directory name in a family of ports), the -compiled.specifics part - should state the compiled-in defaults (the hyphen is - optional). Examples are paper size and font + states the compiled-in defaults. The hyphen is + optional. Examples are paper size and font units. The -compiled.specifics - part is set in the PKGNAMESUFFIX - variable. + part is set in PKGNAMESUFFIX. @@ -446,9 +452,9 @@ PORTEPOCH= 1 beta, rc, or pre, take the first letter and put it immediately after a period. If the version string - continues after those names, the numbers should follow + continues after those names, the numbers follow the single alphabet without an extra period between - them. + them (for example, 1.0b2). The idea is to make it easier to sort ports by looking at the version string. In particular, make sure @@ -461,26 +467,28 @@ PORTEPOCH= 1 yy.mm.dd format. It is important to prefix the version with 0.0. in case a release with an actual - version number is made, which would of course be + version number is made, which would be numerically less than yyyy. - + Package name must be unique among all of the ports tree, check that there is not already a port with the same PORTNAME and if there is add one of PKGNAMEPREFIX or PKGNAMESUFFIX. - + Here are some (real) examples on how to convert the name as called by the software authors to a suitable package name: - + + Package Naming Examples + @@ -504,6 +512,15 @@ PORTEPOCH= 1 + mule-1.0.1 + (empty) + mule + 1 + 1.0.1 + mule already exists + + + EmiClock-1.0.2 (empty) emiclock @@ -608,14 +625,15 @@ PORTEPOCH= 1 - +
If there is absolutely no trace of version information in the original source and it is unlikely that the original author will ever release another version, just set the version string to 1.0 (like the piewm example above). Otherwise, ask the - original author or use the date string + original author or use the date string the source file was + released on (0.0.yyyy.mm.dd) as the version. @@ -637,12 +655,12 @@ PORTEPOCH= 1 packages on the FTP site or the CDROM. Please take a look at the current list of categories and pick the ones that are suitable for - your port. + the port. This list also determines where in the ports tree the port - is imported. If you put more than one category here, it is - assumed that the port files will be put in the subdirectory - with the name in the first category. See + is imported. If there is more than one category here, + the port files must be put in the subdirectory + with the name of the first category. See below for more discussion about how to pick the right categories. @@ -658,8 +676,8 @@ PORTEPOCH= 1 purposes. - For non-virtual categories, you will find a one-line - description in the COMMENT in that + For non-virtual categories, there is a one-line + description in COMMENT in that subdirectory's Makefile. @@ -740,7 +758,7 @@ PORTEPOCH= 1 comms Communication software. - Mostly software to talk to your serial + Mostly software to talk to the serial port. @@ -767,9 +785,9 @@ PORTEPOCH= 1 devel Development utilities. Do not put libraries here just because they are - libraries—unless they truly do not belong - anywhere else, they should not be in this - category. + libraries. They should not be + in this category unless they truly do not belong + anywhere else. @@ -788,8 +806,10 @@ PORTEPOCH= 1 editors General editors. Specialized editors go in the section for those - tools (e.g., a mathematical-formula editor will go - in math). + tools. For example, a mathematical-formula editor will + go in math, and have + editors as a second + category. @@ -802,7 +822,7 @@ PORTEPOCH= 1 emulators Emulators for other operating systems. Terminal emulators do not - belong here—X-based ones should go to + belong here. X-based ones go to x11 and text-based ones to either comms or misc, depending on the exact @@ -824,8 +844,8 @@ PORTEPOCH= 1 ftp - FTP client and server utilities. - If your port speaks both FTP and HTTP, put it + FTP client and server utilities. + If the port speaks both FTP and HTTP, put it in ftp with a secondary category of www. @@ -984,10 +1004,10 @@ PORTEPOCH= 1 misc Miscellaneous utilities - Basically things that do not belong anywhere + Things that do not belong anywhere else. If at all possible, try to find a better - category for your port than misc, - as ports tend to get overlooked in here. + category for the port than misc, + as ports tend to be overlooked in here. @@ -1212,7 +1232,7 @@ PORTEPOCH= 1 The X Window System and friends. This category is only for software that directly supports the window system. Do not put regular X - applications here; most of them should go into other + applications here. Most of them go into other x11-* categories (see below). @@ -1288,9 +1308,9 @@ PORTEPOCH= 1 Choosing the Right Category - As many of the categories overlap, you often have to - choose which of the categories should be the primary category - of your port. There are several rules that govern this issue. + As many of the categories overlap, choosing which of the + categories will be the primary category of the port can be + tedious. There are several rules that govern this issue. Here is the list of priorities, in decreasing order of precedence: @@ -1305,16 +1325,16 @@ PORTEPOCH= 1 Language specific categories always come first. For - example, if your port installs Japanese X11 fonts, then - your CATEGORIES line would read + example, if the port installs Japanese X11 fonts, then + the CATEGORIES line would read japanese x11-fonts. Specific categories are listed before less-specific - ones. For instance, an HTML editor should be listed as + ones. For instance, an HTML editor is listed as www editors, not the other way - around. Also, you should not list + around. Also, do not list net when the port belongs to any of irc, mail, news, security, @@ -1325,49 +1345,50 @@ PORTEPOCH= 1 x11 is used as a secondary category only when the primary category is a natural - language. In particular, you should not put + language. In particular, do not put x11 in the category line for X applications. - Emacs modes should be + Emacs modes are placed in the same ports category as the application supported by the mode, not in editors. For example, an Emacs mode to edit source files - of some programming language should go into + of some programming language goes into lang. - Ports which install loadable kernel modules should + Ports installing loadable kernel modules also have the virtual category kld in their CATEGORIES line. This is one of the things handled automatically by adding - kmod to the USES - line. + USES=kmod. - misc should not appear with any - other non-virtual category. If you have - misc with something else in your - CATEGORIES line, that means you can - safely delete misc and just put the - port in that other subdirectory! + misc does not appear with any + other non-virtual category. If there is + misc with something else in + CATEGORIES, that means + misc can safely be deleted and the port + placed only in the other subdirectory. - If your port truly does not belong anywhere else, + If the port truly does not belong anywhere else, put it in misc. - If you are not sure about the category, please put a - comment to that effect in your &man.send-pr.1; submission so - we can discuss it before we import it. If you are a - committer, send a note to the &a.ports; so we can discuss it + If the category is not clearly defined, please put a + comment to that effect in the port + submission in the bug database so + we can discuss it before we import it. As a committer, + send a note to the &a.ports; so we can discuss it first. Too often, new ports are imported to the wrong category only to be moved right away. This causes unnecessary and undesirable bloat in the master source repository. @@ -1381,9 +1402,9 @@ PORTEPOCH= 1 virtual categories—those that do not have a corresponding subdirectory in the ports tree— or physical categories—those that - do. The following text discusses the issues involved in - creating a new physical category so that you can understand - them before you propose one. + do. This section discusses the issues involved in creating a + new physical category. Read it thouroughly before proposing a + new one. Our existing practice has been to avoid creating a new physical category unless either a large number of ports would @@ -1407,15 +1428,15 @@ PORTEPOCH= 1 - Propose the new category on &a.ports;. You should - include a detailed rationale for the new category, - including why you feel the existing categories are not + Propose the new category on &a.ports;. Include + a detailed rationale for the new category, + including why the existing categories are not sufficient, and the list of existing ports proposed to move. (If there are new ports pending in - GNATS that would fit this + Bugzilla that would fit this category, list them too.) If you are the maintainer and/or submitter, respectively, mention that as it may - help you to make your case. + help the case. @@ -1423,10 +1444,10 @@ PORTEPOCH= 1 - If it seems that there is support for your idea, file + If it seems that there is support for the idea, file a PR which includes both the rationale and the list of existing ports that need to be moved. Ideally, this PR - should also include patches for the following: + would also include these patches: @@ -1450,7 +1471,7 @@ PORTEPOCH= 1 - (for extra credit, you can include the other files + (for extra credit, include the other files that have to change, as per the procedure in the Committer's Guide.) @@ -1459,9 +1480,9 @@ PORTEPOCH= 1 Since it affects the ports infrastructure and involves - not only performing repo-copies but also possibly running - regression tests on the build cluster, the PR should be - assigned to the &a.portmgr;. + moving and patching many ports but also possibly running + regression tests on the build cluster, assign the PR to + the &a.portmgr;. @@ -1472,10 +1493,10 @@ PORTEPOCH= 1 - Proposing a new virtual category should be similar to the + Proposing a new virtual category is similar to the above but much less involved, since no ports will actually have to move. In this case, the only patches to include in - the PR would be those to add the new category to the + the PR would be those to add the new category to CATEGORIES of the affected ports. @@ -1489,8 +1510,8 @@ PORTEPOCH= 1 effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. Please read the history of these proposals in - the mailing list archives before you post this idea; - furthermore, you should be prepared to be challenged to offer + the mailing list archives before posting this idea. + Furthermore, be prepared to be challenged to offer a working prototype. @@ -1499,8 +1520,8 @@ PORTEPOCH= 1 The Distribution Files The second part of the Makefile - describes the files that must be downloaded in order to build - the port, and where they can be downloaded from. + describes the files that must be downloaded to build + the port, and where they can be downloaded. <varname>DISTVERSION/DISTNAME</varname> @@ -1528,9 +1549,9 @@ PORTEPOCH= 1 Only one of PORTVERSION and - DISTVERSION can be set at a time. If you - set DISTVERSION and the derived - PORTVERSION is not right, do not use + DISTVERSION can be set at a time. If + DISTVERSION does not derive a correct + PORTVERSION, do not use DISTVERSION, set PORTVERSION to the right value and set DISTNAME with PORTNAME @@ -1539,11 +1560,11 @@ PORTEPOCH= 1 version. - The following table lists some examples of - DISTVERSION and the derived - PORTVERSION: - + + Examples of <varname>DISTVERSION</varname> and the + Derived <varname>PORTVERSION</varname> + @@ -1574,19 +1595,19 @@ PORTEPOCH= 1 - +
PKGNAMEPREFIX and PKGNAMESUFFIX do not affect DISTNAME. Also note that if WRKSRC is equal to - work/${DISTNAME} while + ${WRKDIR}/${DISTNAME} while the original source archive is named something other than ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}, - you should probably leave DISTNAME - alone— you are better off defining - DISTFILES than having to set both + leave DISTNAME + alone— defining only + DISTFILES is easier than both DISTNAME and WRKSRC (and possibly EXTRACT_SUFX). @@ -1604,7 +1625,7 @@ PORTEPOCH= 1 FETCH if they cannot find it already on the system. - It is recommended that you put multiple sites on this + It is recommended that multiple sites are included on this list, preferably from different continents. This will safeguard against wide-area network problems. We are even planning to add support for automatically determining the @@ -1612,20 +1633,20 @@ PORTEPOCH= 1 sites will go a long way towards helping this effort. If the original tarball is part of one of the popular - archives such as SourceForge, GNU, or Perl CPAN, you may be - able refer to those sites in an easy compact form using - predefined macros (e.g., SF, - GNU or CPAN). Simply - set MASTER_SITES to one of these values. + archives such as SourceForge, GNU, or Perl CPAN, it may be + possible refer to those sites in an easy compact form using + predefined macros (for example, SF, + GNU or CPAN). + Set MASTER_SITES to one of these values. Here is an example: MASTER_SITES= GNU/make - Or you can use the older expanded format, though there - really are no reason to do so: + The older expanded format can still be used, although there + really is no reason to do so: MASTER_SITES= ${MASTER_SITE_GNU} -MASTER_SITE_SUBDIR= make + MASTER_SITE_SUBDIR= make These values and variables are defined in /usr/ports/Mk/bsd.sites.mk. There are @@ -1635,7 +1656,7 @@ MASTER_SITE_SUBDIR= makeSeveral magic macros exist for popular sites with a predictable directory structure. For these, just use the abbreviation and the system will try to - guess the correct subdirectory for you. + guess the correct subdirectory automatically. MASTER_SITES= SF @@ -1647,7 +1668,7 @@ MASTER_SITE_SUBDIR= makeThis can also be written as MASTER_SITES= SF -MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} + MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} Popular Magic <varname>MASTER_SITES</varname> @@ -1828,11 +1849,11 @@ MASTER_SITE_SUBDIR= stardict/WyabdcRealP this (slightly stripped for the example):</para> <programlisting>PORTNAME= pkg -PORTVERSION= 1.2.7 + PORTVERSION= 1.2.7 -USE_GITHUB= yes -GH_ACCOUNT= freebsd -GH_COMMIT= f53e577</programlisting> + USE_GITHUB= yes + GH_ACCOUNT= freebsd + GH_COMMIT= f53e577</programlisting> <para>It will automatically have <varname>MASTER_SITES</varname> set to <literal>GH @@ -1852,13 +1873,13 @@ GH_COMMIT= f53e577</programlisting> this (slightly stripped for the example):</para> <programlisting>PORTNAME= pkg-devel -PORTVERSION= 1.3.0.a.20140411 + PORTVERSION= 1.3.0.a.20140411 -USE_GITHUB= yes -GH_ACCOUNT= freebsd -GH_PROJECT= pkg -GH_TAGNAME= ${GH_COMMIT} -GH_COMMIT= 6dbb17b</programlisting> + USE_GITHUB= yes + GH_ACCOUNT= freebsd + GH_PROJECT= pkg + GH_TAGNAME= ${GH_COMMIT} + GH_COMMIT= 6dbb17b</programlisting> <para>It will automatically have <varname>MASTER_SITES</varname> set to <literal>GH @@ -1872,16 +1893,16 @@ GH_COMMIT= 6dbb17b</programlisting> <sect2 xml:id="makefile-extract_sufx"> <title><varname>EXTRACT_SUFX</varname> - If you have one distribution file, and it uses an odd + If there is one distribution file, and it uses an odd suffix to indicate the compression mechanism, set EXTRACT_SUFX. For example, if the distribution file was named foo.tar.gzip instead of the more normal - foo.tar.gz, you would write: + foo.tar.gz, write:DISTNAME= foo -EXTRACT_SUFX= .tar.gzip + EXTRACT_SUFX= .tar.gzipThe USES=tar[:xxx], @@ -1893,9 +1914,8 @@ EXTRACT_SUFX= .tar.gzip .tar.gz. - You never need to set both - EXTRACT_SUFX and - DISTFILES. + As EXTRACT_SUFX is only used in + DISTFILES, only set one of them.. @@ -1929,11 +1949,11 @@ EXTRACT_SUFX= .tar.gzipEXTRACT_ONLY.DISTFILES= source.tar.gz manual.html -EXTRACT_ONLY= source.tar.gz + EXTRACT_ONLY= source.tar.gz - If none of the - DISTFILES should be uncompressed then set - EXTRACT_ONLY to the empty string. + When none of the DISTFILES need to be + uncompressed, set EXTRACT_ONLY to the empty + string.EXTRACT_ONLY= @@ -1941,14 +1961,14 @@ EXTRACT_ONLY= source.tar.gz<varname>PATCHFILES</varname> - If your port requires some additional patches that are - available by FTP or HTTP, set PATCHFILES to + If the port requires some additional patches that are + available by FTP or HTTP, set PATCHFILES to the names of the files and PATCH_SITES to the URL of the directory that contains them (the format is the same as MASTER_SITES). If the patch is not relative to the top of the source tree - (i.e., WRKSRC) because it contains some + (that is, WRKSRC) because it contains some extra pathnames, set PATCH_DIST_STRIP accordingly. For instance, if all the pathnames in the patch have an extra foozolix-1.0/ in front of the @@ -1961,16 +1981,16 @@ EXTRACT_ONLY= source.tar.gz.bz2 or .xz. *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***