head 1.93; access; symbols pkgsrc-2026Q1:1.93.0.2 pkgsrc-2026Q1-base:1.93 pkgsrc-2025Q4:1.92.0.12 pkgsrc-2025Q4-base:1.92 pkgsrc-2025Q3:1.92.0.10 pkgsrc-2025Q3-base:1.92 pkgsrc-2025Q2:1.92.0.8 pkgsrc-2025Q2-base:1.92 pkgsrc-2025Q1:1.92.0.6 pkgsrc-2025Q1-base:1.92 pkgsrc-2024Q4:1.92.0.4 pkgsrc-2024Q4-base:1.92 pkgsrc-2024Q3:1.92.0.2 pkgsrc-2024Q3-base:1.92 pkgsrc-2024Q2:1.90.0.2 pkgsrc-2024Q2-base:1.90 pkgsrc-2024Q1:1.89.0.10 pkgsrc-2024Q1-base:1.89 pkgsrc-2023Q4:1.89.0.8 pkgsrc-2023Q4-base:1.89 pkgsrc-2023Q3:1.89.0.6 pkgsrc-2023Q3-base:1.89 pkgsrc-2023Q2:1.89.0.4 pkgsrc-2023Q2-base:1.89 pkgsrc-2023Q1:1.89.0.2 pkgsrc-2023Q1-base:1.89 pkgsrc-2022Q4:1.88.0.4 pkgsrc-2022Q4-base:1.88 pkgsrc-2022Q3:1.88.0.2 pkgsrc-2022Q3-base:1.88 pkgsrc-2022Q2:1.87.0.2 pkgsrc-2022Q2-base:1.87 pkgsrc-2022Q1:1.86.0.8 pkgsrc-2022Q1-base:1.86 pkgsrc-2021Q4:1.86.0.6 pkgsrc-2021Q4-base:1.86 pkgsrc-2021Q3:1.86.0.4 pkgsrc-2021Q3-base:1.86 pkgsrc-2021Q2:1.86.0.2 pkgsrc-2021Q2-base:1.86 pkgsrc-2021Q1:1.85.0.8 pkgsrc-2021Q1-base:1.85 pkgsrc-2020Q4:1.85.0.6 pkgsrc-2020Q4-base:1.85 pkgsrc-2020Q3:1.85.0.4 pkgsrc-2020Q3-base:1.85 pkgsrc-2020Q2:1.85.0.2 pkgsrc-2020Q2-base:1.85 pkgsrc-2020Q1:1.80.0.2 pkgsrc-2020Q1-base:1.80 pkgsrc-2019Q4:1.79.0.8 pkgsrc-2019Q4-base:1.79 pkgsrc-2019Q3:1.79.0.4 pkgsrc-2019Q3-base:1.79 pkgsrc-2019Q2:1.79.0.2 pkgsrc-2019Q2-base:1.79 pkgsrc-2019Q1:1.78.0.18 pkgsrc-2019Q1-base:1.78 pkgsrc-2018Q4:1.78.0.16 pkgsrc-2018Q4-base:1.78 pkgsrc-2018Q3:1.78.0.14 pkgsrc-2018Q3-base:1.78 pkgsrc-2018Q2:1.78.0.12 pkgsrc-2018Q2-base:1.78 pkgsrc-2018Q1:1.78.0.10 pkgsrc-2018Q1-base:1.78 pkgsrc-2017Q4:1.78.0.8 pkgsrc-2017Q4-base:1.78 pkgsrc-2017Q3:1.78.0.6 pkgsrc-2017Q3-base:1.78 pkgsrc-2017Q2:1.78.0.2 pkgsrc-2017Q2-base:1.78 pkgsrc-2017Q1:1.77.0.10 pkgsrc-2017Q1-base:1.77 pkgsrc-2016Q4:1.77.0.8 pkgsrc-2016Q4-base:1.77 pkgsrc-2016Q3:1.77.0.6 pkgsrc-2016Q3-base:1.77 pkgsrc-2016Q2:1.77.0.4 pkgsrc-2016Q2-base:1.77 pkgsrc-2016Q1:1.77.0.2 pkgsrc-2016Q1-base:1.77 pkgsrc-2015Q4:1.76.0.4 pkgsrc-2015Q4-base:1.76 pkgsrc-2015Q3:1.76.0.2 pkgsrc-2015Q3-base:1.76 pkgsrc-2015Q2:1.72.0.2 pkgsrc-2015Q2-base:1.72 pkgsrc-2015Q1:1.71.0.8 pkgsrc-2015Q1-base:1.71 pkgsrc-2014Q4:1.71.0.6 pkgsrc-2014Q4-base:1.71 pkgsrc-2014Q3:1.71.0.4 pkgsrc-2014Q3-base:1.71 pkgsrc-2014Q2:1.71.0.2 pkgsrc-2014Q2-base:1.71 pkgsrc-2014Q1:1.64.0.14 pkgsrc-2014Q1-base:1.64 pkgsrc-2013Q4:1.64.0.12 pkgsrc-2013Q4-base:1.64 pkgsrc-2013Q3:1.64.0.10 pkgsrc-2013Q3-base:1.64 pkgsrc-2013Q2:1.64.0.8 pkgsrc-2013Q2-base:1.64 pkgsrc-2013Q1:1.64.0.6 pkgsrc-2013Q1-base:1.64 pkgsrc-2012Q4:1.64.0.4 pkgsrc-2012Q4-base:1.64 pkgsrc-2012Q3:1.64.0.2 pkgsrc-2012Q3-base:1.64 pkgsrc-2012Q2:1.63.0.8 pkgsrc-2012Q2-base:1.63 pkgsrc-2012Q1:1.63.0.6 pkgsrc-2012Q1-base:1.63 pkgsrc-2011Q4:1.63.0.4 pkgsrc-2011Q4-base:1.63 pkgsrc-2011Q3:1.63.0.2 pkgsrc-2011Q3-base:1.63 pkgsrc-2011Q2:1.61.0.16 pkgsrc-2011Q2-base:1.61 pkgsrc-2011Q1:1.61.0.14 pkgsrc-2011Q1-base:1.61 pkgsrc-2010Q4:1.61.0.12 pkgsrc-2010Q4-base:1.61 pkgsrc-2010Q3:1.61.0.10 pkgsrc-2010Q3-base:1.61 pkgsrc-2010Q2:1.61.0.8 pkgsrc-2010Q2-base:1.61 pkgsrc-2010Q1:1.61.0.6 pkgsrc-2010Q1-base:1.61 pkgsrc-2009Q4:1.61.0.4 pkgsrc-2009Q4-base:1.61 pkgsrc-2009Q3:1.61.0.2 pkgsrc-2009Q3-base:1.61 pkgsrc-2009Q2:1.60.0.2 pkgsrc-2009Q2-base:1.60 pkgsrc-2009Q1:1.59.0.2 pkgsrc-2009Q1-base:1.59 pkgsrc-2008Q4:1.56.0.6 pkgsrc-2008Q4-base:1.56 pkgsrc-2008Q3:1.56.0.4 pkgsrc-2008Q3-base:1.56 cube-native-xorg:1.56.0.2 cube-native-xorg-base:1.56 pkgsrc-2008Q2:1.51.0.4 pkgsrc-2008Q2-base:1.51 cwrapper:1.51.0.2 pkgsrc-2008Q1:1.48.0.4 pkgsrc-2008Q1-base:1.48 pkgsrc-2007Q4:1.48.0.2 pkgsrc-2007Q4-base:1.48 pkgsrc-2007Q3:1.47.0.2 pkgsrc-2007Q3-base:1.47 pkgsrc-2007Q2:1.46.0.2 pkgsrc-2007Q2-base:1.46 pkgsrc-2007Q1:1.44.0.2 pkgsrc-2007Q1-base:1.44 pkgsrc-2006Q4:1.42.0.2 pkgsrc-2006Q4-base:1.42 pkgsrc-2006Q3:1.35.0.2 pkgsrc-2006Q3-base:1.35 pkgsrc-2006Q2:1.29.0.2 pkgsrc-2006Q2-base:1.29 pkgsrc-2006Q1:1.25.0.2 pkgsrc-2006Q1-base:1.25 pkgsrc-2005Q4:1.17.0.2 pkgsrc-2005Q4-base:1.17 pkgsrc-2005Q3:1.10.0.2 pkgsrc-2005Q3-base:1.10 pkgsrc-2005Q2:1.8.0.2 pkgsrc-2005Q2-base:1.8 pkgsrc-2005Q1:1.3.0.4 pkgsrc-2005Q1-base:1.3 pkgsrc-2004Q4:1.3.0.2 pkgsrc-2004Q4-base:1.3 pkgsrc-base:1.1.1.1 TNF:1.1.1; locks; strict; comment @# @; 1.93 date 2026.02.08.09.42.35; author wiz; state Exp; branches; next 1.92; commitid TTmvaxKi5a9kxytG; 1.92 date 2024.08.25.06.18.39; author wiz; state Exp; branches; next 1.91; commitid BcrSL94SO85mvanF; 1.91 date 2024.08.20.18.02.04; author gdt; state Exp; branches; next 1.90; commitid Niu5OC3PRXNOyAmF; 1.90 date 2024.05.08.10.34.12; author cheusov; state Exp; branches; next 1.89; commitid 1HpcezMlVB6wqb9F; 1.89 date 2023.01.20.12.21.56; author wiz; state Exp; branches; next 1.88; commitid zIXu9jZwRqx4ghaE; 1.88 date 2022.07.25.05.42.22; author rillig; state Exp; branches; next 1.87; commitid G9lSkNRSeebGNeND; 1.87 date 2022.05.21.11.42.29; author nia; state Exp; branches; next 1.86; commitid FQWyrdsIyYgPSUED; 1.86 date 2021.04.06.17.21.17; author nia; state Exp; branches; next 1.85; commitid fdgGUF3xXFU9WfOC; 1.85 date 2020.06.20.15.25.01; author rillig; state Exp; branches; next 1.84; commitid Lmc5VoUrCVV9CYcC; 1.84 date 2020.06.20.04.18.41; author rillig; state Exp; branches; next 1.83; commitid PNOQ1Uw8i8uhVUcC; 1.83 date 2020.06.05.17.05.22; author rillig; state Exp; branches; next 1.82; commitid ulEQxx3qaGdpE3bC; 1.82 date 2020.06.02.06.10.09; author rillig; state Exp; branches; next 1.81; commitid izxd1qTEvVmS5CaC; 1.81 date 2020.05.03.08.27.10; author rillig; state Exp; branches; next 1.80; commitid kfSQvXhPhG2tQL6C; 1.80 date 2020.02.24.21.13.56; author rillig; state Exp; branches; next 1.79; commitid iOJqEaJcH6FXiYXB; 1.79 date 2019.05.05.18.36.05; author rillig; state Exp; branches; next 1.78; commitid yarKuc4oEkvnU2mB; 1.78 date 2017.05.26.17.59.37; author leot; state Exp; branches; next 1.77; commitid shPLjELThy5OuVSz; 1.77 date 2016.03.29.11.32.58; author tnn; state Exp; branches; next 1.76; commitid ZbXhFMCiYsoCXw0z; 1.76 date 2015.08.31.11.54.29; author leot; state Exp; branches; next 1.75; commitid AgcDMv88g1GdPpzy; 1.75 date 2015.07.04.16.20.35; author joerg; state Exp; branches; next 1.74; commitid KwFaUi9N0rgncZry; 1.74 date 2015.07.04.16.12.54; author joerg; state Exp; branches; next 1.73; commitid WoOAw701k04I9Zry; 1.73 date 2015.06.29.11.06.46; author ryoon; state Exp; branches; next 1.72; commitid TCXbyMTKtwxACjry; 1.72 date 2015.05.08.20.26.19; author bsiegert; state Exp; branches; next 1.71; commitid PvHuNaJXKNoYmGky; 1.71 date 2014.05.31.21.08.50; author asau; state Exp; branches; next 1.70; commitid ZlBSYUdz0HnrCJCx; 1.70 date 2014.05.19.14.31.54; author obache; state Exp; branches; next 1.69; commitid Y2VCmuNavDVSN9Bx; 1.69 date 2014.05.19.13.59.15; author wiz; state Exp; branches; next 1.68; commitid zI3rRErtIziZC9Bx; 1.68 date 2014.05.19.13.47.22; author obache; state Exp; branches; next 1.67; commitid 7l8I6XcODZNny9Bx; 1.67 date 2014.05.19.13.42.51; author obache; state Exp; branches; next 1.66; commitid 9pUOEcAF0gFMw9Bx; 1.66 date 2014.05.19.13.16.56; author obache; state Exp; branches; next 1.65; commitid 1ZYfBPfNjtsoo9Bx; 1.65 date 2014.05.19.13.15.10; author obache; state Exp; branches; next 1.64; commitid BO2duX0OT3LOn9Bx; 1.64 date 2012.09.19.15.26.34; author wiz; state Exp; branches; next 1.63; 1.63 date 2011.08.04.13.50.07; author kano; state Exp; branches; next 1.62; 1.62 date 2011.07.31.08.48.22; author spz; state Exp; branches; next 1.61; 1.61 date 2009.08.02.02.41.53; author joerg; state Exp; branches; next 1.60; 1.60 date 2009.04.09.00.51.31; author joerg; state Exp; branches; next 1.59; 1.59 date 2009.04.03.01.52.24; author snj; state Exp; branches; next 1.58; 1.58 date 2009.02.11.05.05.20; author kano; state Exp; branches; next 1.57; 1.57 date 2009.02.10.19.24.37; author joerg; state Exp; branches; next 1.56; 1.56 date 2008.09.09.00.59.51; author obache; state Exp; branches; next 1.55; 1.55 date 2008.07.27.19.27.37; author joerg; state Exp; branches; next 1.54; 1.54 date 2008.07.23.15.33.44; author kano; state Exp; branches; next 1.53; 1.53 date 2008.07.22.13.14.21; author wiz; state Exp; branches; next 1.52; 1.52 date 2008.07.22.10.39.36; author agc; state Exp; branches; next 1.51; 1.51 date 2008.05.27.15.06.25; author kano; state Exp; branches; next 1.50; 1.50 date 2008.05.26.13.38.12; author joerg; state Exp; branches; next 1.49; 1.49 date 2008.05.25.20.52.01; author joerg; state Exp; branches; next 1.48; 1.48 date 2007.12.12.01.03.33; author markd; state Exp; branches; next 1.47; 1.47 date 2007.08.15.06.33.44; author rillig; state Exp; branches; next 1.46; 1.46 date 2007.06.01.11.07.24; author rillig; state Exp; branches; next 1.45; 1.45 date 2007.04.19.16.54.58; author joerg; state Exp; branches; next 1.44; 1.44 date 2007.03.03.13.27.03; author kano; state Exp; branches; next 1.43; 1.43 date 2007.03.02.09.38.21; author wiz; state Exp; branches; next 1.42; 1.42 date 2006.12.15.13.22.14; author martti; state Exp; branches; next 1.41; 1.41 date 2006.12.08.19.06.41; author drochner; state Exp; branches; next 1.40; 1.40 date 2006.12.04.12.39.52; author kano; state Exp; branches; next 1.39; 1.39 date 2006.12.02.06.03.31; author kano; state Exp; branches; next 1.38; 1.38 date 2006.11.23.11.47.54; author yyamano; state Exp; branches; next 1.37; 1.37 date 2006.11.10.21.36.37; author schwarz; state Exp; branches; next 1.36; 1.36 date 2006.10.09.13.15.07; author mishka; state Exp; branches; next 1.35; 1.35 date 2006.09.13.23.23.00; author wiz; state Exp; branches; next 1.34; 1.34 date 2006.09.10.19.51.49; author wiz; state Exp; branches; next 1.33; 1.33 date 2006.09.09.23.47.40; author wiz; state Exp; branches; next 1.32; 1.32 date 2006.09.09.04.21.30; author obache; state Exp; branches; next 1.31; 1.31 date 2006.07.30.00.30.55; author wiz; state Exp; branches; next 1.30; 1.30 date 2006.07.24.10.32.36; author rillig; state Exp; branches; next 1.29; 1.29 date 2006.06.27.11.07.12; author rillig; state Exp; branches; next 1.28; 1.28 date 2006.06.26.23.28.51; author rillig; state Exp; branches; next 1.27; 1.27 date 2006.04.21.07.54.12; author rillig; state Exp; branches; next 1.26; 1.26 date 2006.04.21.07.30.32; author rillig; state Exp; branches; next 1.25; 1.25 date 2006.02.18.17.11.50; author rillig; state Exp; branches; next 1.24; 1.24 date 2006.02.17.20.38.17; author rillig; state Exp; branches; next 1.23; 1.23 date 2006.02.12.14.44.59; author rillig; state Exp; branches; next 1.22; 1.22 date 2006.01.27.04.06.25; author rillig; state Exp; branches; next 1.21; 1.21 date 2006.01.13.17.55.27; author reed; state Exp; branches; next 1.20; 1.20 date 2006.01.12.21.46.33; author wiz; state Exp; branches; next 1.19; 1.19 date 2006.01.11.22.35.31; author rillig; state Exp; branches; next 1.18; 1.18 date 2006.01.07.21.42.34; author rillig; state Exp; branches; next 1.17; 1.17 date 2005.11.04.11.55.31; author rillig; state Exp; branches; next 1.16; 1.16 date 2005.11.03.19.29.54; author rillig; state Exp; branches; next 1.15; 1.15 date 2005.11.03.19.06.50; author rillig; state Exp; branches; next 1.14; 1.14 date 2005.11.03.18.15.47; author rillig; state Exp; branches; next 1.13; 1.13 date 2005.11.03.17.06.13; author rillig; state Exp; branches; next 1.12; 1.12 date 2005.11.03.16.43.59; author rillig; state Exp; branches; next 1.11; 1.11 date 2005.10.23.11.25.58; author rillig; state Exp; branches; next 1.10; 1.10 date 2005.09.02.19.12.37; author rillig; state Exp; branches; next 1.9; 1.9 date 2005.07.27.21.29.50; author rpaulo; state Exp; branches; next 1.8; 1.8 date 2005.06.01.20.58.16; author wiz; state Exp; branches; next 1.7; 1.7 date 2005.05.24.12.14.42; author wiz; state Exp; branches; next 1.6; 1.6 date 2005.05.24.11.11.24; author rillig; state Exp; branches; next 1.5; 1.5 date 2005.05.14.22.34.59; author rillig; state Exp; branches; next 1.4; 1.4 date 2005.05.08.13.53.06; author wiz; state Exp; branches; next 1.3; 1.3 date 2004.12.03.12.48.15; author wiz; state Exp; branches; next 1.2; 1.2 date 2004.11.22.16.50.01; author wiz; state Exp; branches; next 1.1; 1.1 date 2004.10.21.14.27.38; author grant; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2004.10.21.14.27.38; author grant; state Exp; branches; next ; desc @@ 1.93 log @doc: describe the test phase of a package @ text @ The build process 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 split into so-called stages, which take the name of the containing phase, 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. Never override the regular targets (like fetch), if you have to, override the do-* ones instead. 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 any pkgsrc-specific patches to compile properly 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. To get more details about what is happening at each step, you can set the PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in more details about the patch step. Program location Before outlining the process performed by the &os; package system in the next section, here's a brief discussion on where programs are installed, and which variables influence this. The automatic variable PREFIX indicates where all files of the final program shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for pkgs in the cross category. The value of PREFIX needs to be put into the various places in the program's source where paths to these files are encoded. See and for more details. When choosing which of these variables to use, follow the following rules: PREFIX always points to the location where the current pkg will be installed. When referring to a pkg's own installation path, use ${PREFIX}. LOCALBASE is where all pkgs are installed. If you need to construct a -I or -L argument to the compiler to find includes and libraries installed by another pkg, use ${LOCALBASE}. The name LOCALBASE stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc leaves /usr/local for the system administrator, this variable is a misnomer. X11BASE is where the actual X11 distribution (from xsrc, etc.) is installed. When looking for standard X11 includes (not those installed by a package), use ${X11BASE}. X11-based packages using imake must set USE_IMAKE to be installed correctly under LOCALBASE. Within ${PREFIX}, packages should install files according to &man.hier.7;, with the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/man. Directories used during the build process When building a package, various directories are 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. PKGSRCDIR This is an absolute pathname that points to the pkgsrc root directory. Generally, you don't need it. PKGDIR This is an absolute pathname that points to the current package. PKGPATH This is a pathname relative to PKGSRCDIR that points to the current package. It is defined after including bsd.prefs.mk and can be used in makefile fragments that are used by several packages to distinguish between these packages. Other variables that would serve the same purpose are PKGBASE and PKGNAME, but these are only defined after including bsd.pkg.mk, which is too late. In &mk.conf;, the pkgsrc user can use PKGPATH to tweak variables like MAKE_JOBS and CFLAGS. WRKDIR This is an absolute pathname pointing to the directory where all work takes place. The distfiles are extracted to this directory. It also contains temporary directories and log files used by the various pkgsrc frameworks, like buildlink or the wrappers. WRKSRC 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. This variable may be changed by a package Makefile. The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and defaults to no. It indicates whether a symbolic link to the WRKDIR is to be created in the pkgsrc entry's directory. If users would like to have their pkgsrc trees behave in a read-only manner, then the value of CREATE_WRKDIR_SYMLINK should be set to no. 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. The <emphasis>fetch</emphasis> phase The first step in building a package is to fetch the distribution files (distfiles) from the sites that are providing them. This is the task of the fetch phase. What to fetch and where to get it from In simple cases, MASTER_SITES defines all URLs from where the distfile, whose name is derived from the DISTNAME variable, is fetched. The more complicated cases are described below. The variable DISTFILES specifies the list of distfiles that have to be fetched. Its value defaults to ${DEFAULT_DISTFILES} and its value is ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be changed freely. Note that if your package requires additional distfiles to the default one, you cannot just append the additional filenames using the += operator, but you have write for example: DISTFILES= ${DEFAULT_DISTFILES} additional-files.tar.gz Each distfile is fetched from a list of sites, usually MASTER_SITES. If the package has multiple DISTFILES or multiple PATCHFILES from different sites, you can set SITES.distfile to the list of URLs where the file distfile (including the suffix) can be found. DISTFILES= ${DISTNAME}${EXTRACT_SUFX} DISTFILES+= foo-file.tar.gz SITES.foo-file.tar.gz= \ https://www.somewhere.com/somehow/ \ https://www.somewhereelse.com/mirror/somehow/ When actually fetching the distfiles, each item from MASTER_SITES or SITES.* gets the name of each distfile appended to it, without an intermediate slash. Therefore, all site values have to end with a slash or other separator character. This allows for example to set MASTER_SITES to a URL of a CGI script that gets the name of the distfile as a parameter. In this case, the definition would look like: MASTER_SITES= https://www.example.com/download.cgi?file= The exception to this rule are URLs starting with a dash. In that case the URL is taken as is, fetched and the result stored under the name of the distfile. You can use this style for the case when the download URL style does not match the above common case. For example, if permanent download URL is a redirector to the real download URL, or the download file name is offered by an HTTP Content-Disposition header. In the following example, foo-1.0.0.tar.gz will be created instead of the default v1.0.0.tar.gz. DISTNAME= foo-1.0.0 MASTER_SITES= -https://www.example.com/archive/v1.0.0.tar.gz There are some predefined values for MASTER_SITES, which can be used in packages. The names of the variables should speak for themselves. @@master_sites@@ Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP contains backup sites for packages that are maintained in . MASTER_SITE_LOCAL contains local package source distributions that are maintained in . If you choose one of these predefined sites, you may want to specify a subdirectory of that site. Since these macros may expand to more than one actual site, you must use the following construct to specify a subdirectory: MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/} MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/} Note the trailing slash after the subdirectory name. How are the files fetched? The fetch phase makes sure that all the distfiles exist in a local directory (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they are fetched 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 and the last can be optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and MASTER_SORT_AWK or MASTER_SORT_REGEX. The specific command and arguments used depend on the FETCH_USING parameter. The example above is for FETCH_USING=custom. The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles target to mirror the distfiles, if they are freely distributable. Packages setting NO_SRC_ON_FTP (usually to ${RESTRICTED}) will not have their distfiles mirrored. The <emphasis>checksum</emphasis> 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. The <emphasis>extract</emphasis> phase When the distfiles are present on the local system, they need to be extracted, as they usually come in the form of some compressed archive format. By default, all DISTFILES are extracted. If you only need some of them, you can set the EXTRACT_ONLY variable to the list of those files. Extracting the files is usually done by a little program, mk/extract/extract, which already knows how to extract various archive formats, so most likely you will not need to change anything here. But if you need, the following variables may help you: EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO} Use these variables to override the default options for an extract command, which are defined in mk/extract/extract. EXTRACT_USING This variable can be set to bsdtar, gtar, nbtar (which is the default value), pax, or an absolute pathname pointing to the command with which tar archives should be extracted. It is preferred to choose bsdtar over gtar if NetBSD's pax-as-tar is not good enough. If the extract program doesn't serve your needs, you can also override the EXTRACT_CMD variable, which holds the command used for extracting the files. This command is executed in the ${WRKSRC} directory. During execution of this command, the shell variable extract_file holds the absolute pathname of the file that is going to be extracted. And if that still does not suffice, you can override the do-extract target in the package Makefile. The <emphasis>patch</emphasis> 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 &man.patch.1; can be handed in PATCH_DIST_ARGS. See for more details. By default &man.patch.1; is given special arguments to make it fail if the expected text from the patch context is not found in the patched file. If that happens, fix the patch file by comparing it with the actual text in the file to be patched. The <emphasis>tools</emphasis> phase This is covered in . The <emphasis>wrapper</emphasis> phase This phase creates wrapper programs for the compilers and linkers. The following variables can be used to tweak the wrappers. ECHO_WRAPPER_MSG The command used to print progress messages. Does nothing by default. Set to ${ECHO} to see the progress messages. WRAPPER_DEBUG This variable can be set to yes (default) or no, depending on whether you want additional information in the wrapper log file. WRAPPER_UPDATE_CACHE This variable can be set to yes or no, depending on whether the wrapper should use its cache, which will improve the speed. The default value is yes, but is forced to no if the platform does not support it. WRAPPER_REORDER_CMDS A list of reordering commands. A reordering command has the form reorder:l:lib1:lib2. It ensures that that -llib1 occurs before -llib2. The <emphasis>configure</emphasis> 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. In the do-configure stage, a rough equivalent of the following command is run. See mk/configure/configure.mk, target do-configure-script for the exact definition. .for dir in ${CONFIGURE_DIRS} cd ${WRKSRC} && cd ${dir} \ && env ${CONFIGURE_ENV} \ ${CONFIG_SHELL} ${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 the Perl way of configuration (mainly Perl modules, but not only), i.e. a file called Makefile.PL, it should include ../../lang/perl5/module.mk. To set any parameter for Makefile.PL use the MAKE_PARAMS variable (e.g., MAKE_PARAMS+=foo=bar If the program uses an Imakefile for configuration, the appropriate steps can be invoked by setting USE_IMAKE to yes. If you only need xmkmf, add it to USE_TOOLS. You can add variables to xmkmf's environment by adding them to the SCRIPTS_ENV variable. If the program uses cmake for configuration, the appropriate steps can be invoked by including ../../devel/cmake/build.mk. You can add variables to cmake's environment by adding them to the CONFIGURE_ENV variable and arguments to cmake by adding them to the CMAKE_CONFIGURE_ARGS variable. If you want to add arguments only for particular stages, you can use the CMAKE_CONFIGURE_ARGS, CMAKE_BUILD_ARGS, and CMAKE_INSTALL_ARGS variables. You can set the CONFIGURE_DIRS variable to the directories in which CMake should be run, relative to WRKSRC. This defaults to to .. Any package using the now-deprecated USE_CMAKE=yes should be converted. Essentially, replace with an include of ../../devel/cmake/build.mk, prune creation of a build directory and settings to use it, and check/fix settings that intend to perform the build in a subdirectory. If there is no configure step at all, set NO_CONFIGURE to yes. The <emphasis>build</emphasis> phase For building a package, a rough equivalent of the following code is executed; see mk/build/build.mk, target do-build for the exact definition. .for dir in ${BUILD_DIRS} cd ${WRKSRC} && cd ${dir} \ && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${MAKE_FLAGS} ${BUILD_MAKE_FLAGS} \ -f ${MAKE_FILE} \ ${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, MAKE_FILE 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 MAKE_FILE is Makefile, and BUILD_TARGET defaults to all. If there is no build step at all, set NO_BUILD to yes. The <emphasis>test</emphasis> phase The test phase is for running a program's self tests. Dependencies that are only required for testing can be specified using TEST_DEPENDS. For packages using &man.make.1; for building, you can set TEST_TARGET. Often, the proper value is check or test. If more elaborate steps are needed, you can define a do-test target. To run the tests, call make test. When building a package, the tests are not run automatically, except if PKGSRC_RUN_TEST is set to yes. The <emphasis>install</emphasis> 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. In the install phase, a rough equivalent of the following code is executed; see mk/install/install.mk, target do-install for the exact definition. Additionally, before and after this code, several consistency checks are run against the files-to-be-installed, see mk/check/*.mk for details. .for dir in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${dir} \ && env ${INSTALL_ENV} ${MAKE_ENV} \ ${MAKE_PROGRAM} ${MAKE_FLAGS} ${INSTALL_MAKE_FLAGS} \ -f ${MAKE_FILE} ${INSTALL_TARGET} .endfor The variable's meanings are analogous to the ones in the build phase. INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is install by default, plus install.man if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not defined. In the install phase, the following variables are useful. They are all variations of the &man.install.1; command that have the owner, group and permissions preset. INSTALL is the plain install command. The specialized variants, together with their intended use, are: INSTALL_PROGRAM_DIR directories that contain binaries INSTALL_SCRIPT_DIR directories that contain scripts INSTALL_LIB_DIR directories that contain shared and static libraries INSTALL_DATA_DIR directories that contain data files INSTALL_MAN_DIR directories that contain man pages INSTALL_GAME_DIR directories that contain data files for games INSTALL_PROGRAM binaries that can be stripped from debugging symbols INSTALL_SCRIPT binaries that cannot be stripped INSTALL_GAME game binaries INSTALL_LIB shared and static libraries INSTALL_DATA data files INSTALL_GAME_DATA data files for games INSTALL_MAN man pages Some other variables are: INSTALL_UNSTRIPPED If set to yes, do not run &man.strip.1; when installing binaries. Any debugging sections and symbols present in binaries will be preserved. INSTALLATION_DIRS A list of directories relative to PREFIX that are created by pkgsrc at the beginning of the install phase. The package is supposed to create all needed directories itself before installing files to it and list all other directories here. In the rare cases that a package shouldn't install anything, set NO_INSTALL to yes. This is mostly relevant for packages in the regress category. The <emphasis>package</emphasis> phase Once the install stage has completed, a binary package of the installed files can be built. These binary packages can be used for quick installation without previous compilation, e.g. by the make bin-install or by using pkg_add. By default, the binary packages are created in ${PACKAGES}/All and symlinks are created in ${PACKAGES}/category, one for each category in the CATEGORIES variable. PACKAGES defaults to pkgsrc/packages. Cleaning up Once you're finished with a package, you can clean the work directory by running make clean. If you want to clean the work directories of all dependencies too, use make clean-depends. Other helpful targets pre/post-* For any of the main targets described in the previous section (configure, build, install, etc.), two auxiliary targets exist with pre- and post- used as a prefix for the main target's name. These targets are invoked before and after the main target is called, allowing extra configuration or installation steps be performed from a package's Makefile, for example, which a program's configure script or install target omitted. About 5% of the pkgsrc packages define their custom post-extract target, another 5% define pre-configure, and 10% define post-install. The other pre/post-* targets are defined even less often. do-* Should one of the main targets do the wrong thing, and should there be no variable to fix this, you can redefine it with the do-* target. (Note that redefining the target itself instead of the do-* target is a bad idea, as the pre-* and post-* targets won't be called anymore, etc.) About 15% of the pkgsrc packages override the default do-install, the other do-* targets are overridden even less often. reinstall If you did a make install and you noticed some file was not installed properly, you can repeat the installation with this target, which will ignore the already installed flag. This is the default value of DEPENDS_TARGET except in the case of make update and make package, where the defaults are package and update, respectively. deinstall This target does a &man.pkg.delete.1; in the current directory, effectively de-installing the package. The following variables can be used to tune the behaviour: PKG_VERBOSE Add a "-v" to the &man.pkg.delete.1; command. DEINSTALLDEPENDS Remove all packages that require (depend on) the given package. This can be used to remove any packages that may have been pulled in by a given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding -R to the &man.pkg.delete.1; command line. bin-install Install a binary package from local disk and via FTP from a list of sites (see the BINPKG_SITES variable), and do a make package if no binary package is available anywhere. The arguments given to pkg_add can be set via BIN_INSTALL_FLAGS e.g., to do verbose operation, etc. install-clean This target removes the state files for the "install" and later phases so that the "install" target may be re-invoked. This can be used after editing the PLIST to install the package without rebuilding it. build-clean This target removes the state files for the "build" and later phases so that the "build" target may be re-invoked. update This target causes the current package to be updated to the latest version. The package and all depending packages first get de-installed, then current versions of the corresponding packages get compiled and installed. This is similar to manually noting which packages are currently installed, then performing a series of make deinstall and make install (or whatever UPDATE_TARGET is set to) for these packages. You can use the update target to resume package updating in case a previous make update was interrupted for some reason. However, in this case, make sure you don't call make clean or otherwise remove the list of dependent packages in WRKDIR. Otherwise, you lose the ability to automatically update the current package along with the dependent packages you have installed. Resuming an interrupted make update will only work as long as the package tree remains unchanged. If the source code for one of the packages to be updated has been changed, resuming make update will most certainly fail! The following variables can be used either on the command line or in &mk.conf; to alter the behaviour of make update: UPDATE_TARGET Install target to recursively use for the updated package and the dependent packages. Defaults to DEPENDS_TARGET if set, install otherwise for make update. Other good targets are package or bin-install. Do not set this to update or you will get stuck in an endless loop! NOCLEAN Don't clean up after updating. Useful if you want to leave the work sources of the updated packages around for inspection or other purposes. Be sure you eventually clean up the source tree (see the clean-update target below) or you may run into troubles with old source code still lying around on your next make or make update. REINSTALL Deinstall each package before installing (making DEPENDS_TARGET). This may be necessary if the clean-update target (see below) was called after interrupting a running make update. DEPENDS_TARGET Allows you to disable recursion and hardcode the target for packages. The default is update for the update target, facilitating a recursive update of prerequisite packages. Only set DEPENDS_TARGET if you want to disable recursive updates. Use UPDATE_TARGET instead to just set a specific target for each package to be installed during make update (see above). clean-update Clean the source tree for all packages that would get updated if make update was called from the current directory. This target should not be used if the current package (or any of its depending packages) have already been de-installed (e.g., after calling make update) or you may lose some packages you intended to update. As a rule of thumb: only use this target before the first time you run make update and only if you have a dirty package tree (e.g., if you used NOCLEAN). If you are unsure about whether your tree is clean, you can either perform a make clean at the top of the tree, or use the following sequence of commands from the directory of the package you want to update (before running make update for the first time, otherwise you lose all the packages you wanted to update!): &rprompt; make clean-update &rprompt; make clean CLEANDEPENDS=YES &rprompt; make update The following variables can be used either on the command line or in &mk.conf; to alter the behaviour of make clean-update: CLEAR_DIRLIST After make clean, do not reconstruct the list of directories to update for this package. Only use this if make update successfully installed all packages you wanted to update. Normally, this is done automatically on make update, but may have been suppressed by the NOCLEAN variable (see above). replace Update the installation of the current package. This differs from update in that it does not replace dependent packages. You will need to install pkgtools/pkg_tarup for this target to work. Be careful when using this target! There are no guarantees that dependent packages will still work, in particular they will most certainly break if you make replace a library package whose shared library major version changed between your installed version and the new one. For this reason, this target is not officially supported and only recommended for advanced users. info This target invokes &man.pkg.info.1; for the current package. You can use this to check which version of a package is installed. index This is a top-level command, i.e. it should be used in the pkgsrc directory. It creates a database of all packages in the local pkgsrc tree, including dependencies, comment, maintainer, and some other useful information. Individual entries are created by running make describe in the packages' directories. This index file is saved as pkgsrc/INDEX. It can be displayed in verbose format by running make print-index. You can search in it with make search key=something. You can extract a list of all packages that depend on a particular one by running make show-deps PKG=somepackage. Running this command takes a very long time, some hours even on fast machines! readme This target generates a index.html file, which can be viewed using a browser such as www/firefox or www/links. The generated files contain references to any packages which are in the PACKAGES directory on the local host. The generated files can be made to refer to URLs based on FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate index.html files which pointed to binary packages on the local machine, in the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its subdirectories will be searched for all the binary packages. The target can be run at the toplevel or in category directories, in which case it descends recursively. readme-all This is a top-level command, run it in pkgsrc. Use this target to create a file README-all.html which contains a list of all packages currently available in the &os; Packages Collection, together with the category they belong to and a short description. This file is compiled from the pkgsrc/*/index.html files, so be sure to run this after a make readme. cdrom-readme This is very much the same as the readme target (see above), but is to be used when generating a pkgsrc tree to be written to a CD-ROM. This target also produces index.html files, and can be made to refer to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR. show-distfiles This target shows which distfiles and patchfiles are needed to build the package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not patches/*). show-downlevel This target shows nothing if the package is not installed. If a version of this package is installed, but is not the version provided in this version of pkgsrc, then a warning message is displayed. This target can be used to show which of your installed packages are downlevel, and so the old versions can be deleted, and the current ones added. show-pkgsrc-dir This target shows the directory in the pkgsrc hierarchy from which the package can be built and installed. This may not be the same directory as the one from which the package was installed. This target is intended to be used by people who may wish to upgrade many packages on a single host, and can be invoked from the top-level pkgsrc Makefile by using the show-host-specific-pkgs target. show-installed-depends This target shows which installed packages match the current package's DEPENDS. Useful if out of date dependencies are causing build problems. print-build-depends-list This target shows the list of packages that the current package depends on for building. print-run-depends-list This target shows the list of packages that the current package depends on for running. check-shlibs After a package is installed, check all its binaries and (on ELF platforms) shared libraries to see if they find the shared libs they need. Run by default if PKG_DEVELOPER is set in &mk.conf;. print-PLIST After a make install from a new or upgraded pkg, this prints out an attempt to generate a new PLIST from a find -newer work/.extract_done. An attempt is made to care for shared libs etc., but it is strongly recommended to review the result before putting it into PLIST. On upgrades, it's useful to diff the output of this command against an already existing PLIST file. If the package installs files via &man.tar.1; or other methods that don't update file access times, be sure to add these files manually to your PLIST, as the find -newer command used by this target won't catch them! See for more information on this target. rebuild If you did a make build and you noticed some further modifications of sources are needed, you can repeat the build with this target, which will ignore the already built flag. This target is helpful while working with patches. repackage If you did a make package and you noticed some further modifications of sources are needed, you can repeat the package with this target, which will ignore the already packaged flag. This target is helpful while working with patches, PLIST* files etc. retest If you did a make test and you noticed some further modifications of sources are needed, you can repeat the test with this target, which will ignore the already tested flag. This target is helpful while working with patches. @ 1.92 log @*: replace CMAKE_ARGS with CMAKE_CONFIGURE_ARGS @ text @d1 1 a1 1 d594 12 a605 2 [TODO] @ 1.91 log @doc/guide: Add migration advice for USE_CMAKE @ text @d1 1 a1 1 d529 1 a529 1 by adding them to the CMAKE_ARGS variable. d542 1 a542 3 ../../devel/cmake/build.mk, change CMAKE_ARGS to CMAKE_CONFIGURE_ARGS, prune creation of a build @ 1.90 log @doc/guide: add documentation for targets retest, repackage and rebuild @ text @d1 1 a1 1 d539 10 @ 1.89 log @guide: update documentation for cmake/build.mk @ text @d1 1 a1 1 d1252 37 @ 1.88 log @doc/guide: document how PKGPATH is typically used @ text @d1 1 a1 1 d526 1 a526 1 setting USE_CMAKE to yes. d530 8 a537 3 The top directory argument is given by the CMAKE_ARG_PATH variable, that defaults to . (relative to CONFIGURE_DIRS) @ 1.87 log @very outdated info @ text @d1 1 a1 1 d125 13 a137 2 PKGSRCDIR that points to the current package. d169 5 a173 4 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, @ 1.86 log @update for transition from README.html @ text @d1 1 a1 1 d67 1 a67 1 LOCALBASE is where all non-X11 pkgs d70 1 a70 1 another non-X11 pkg, use ${LOCALBASE}. The name @ 1.85 log @doc/guide: document the default do-* targets more precisely @ text @d1 1 a1 1 d1072 1 a1072 1 README.html file, which can be d1081 1 a1081 1 wanted to generate README.html d1106 1 a1106 1 pkgsrc/*/README.html files, so be sure d1120 1 a1120 1 README.html files, and can be made @ 1.84 log @doc/guide: add usage statistics for the {pre,do,post}-* targets Just to give a broad orientation about which of these targets are usual and which are not. @ text @d1 1 a1 1 d470 7 a476 2 yes instead. What happens in the configure phase is roughly: d479 4 a482 4 .for d in ${CONFIGURE_DIRS} cd ${WRKSRC} \ && cd ${d} \ && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS} d529 3 a531 2 For building a package, a rough equivalent of the following code is executed. d534 2 a535 3 .for d in ${BUILD_DIRS} cd ${WRKSRC} \ && cd ${d} \ d537 1 a537 1 ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ d580 7 a586 4 In the install phase, a rough equivalent of the following code is executed. Additionally, before and after this code, much magic is performed to do consistency checks, registering the package, and so on. d589 5 a593 7 .for d in ${INSTALL_DIRS} cd ${WRKSRC} \ && cd ${d} \ && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ -f ${MAKE_FILE} \ ${INSTALL_TARGET} @ 1.83 log @mk, doc: remove obsolete bulk-install and bulk-package targets @ text @d1 1 a1 1 d720 3 a722 2 For any of the main targets described in the previous section, two auxiliary targets exist with d730 5 d747 5 a751 2 anymore, etc.) You will not usually need to do this. @ 1.82 log @doc/guide: reword paragraph about patches applying cleanly The previous wording was too easy to get wrong. Applying cleanly mainly means that the context lines are as expected. In most cases this is good enough. Having the exact line information would be nice as well, but if this were crucial, pkgtools/pkgdiff would need to fix this sitation. Since it doesn't and even states in a comment that it doesn't, the situation can't be that bad. @ text @d1 1 a1 1 a1219 51 bulk-package Used to do bulk builds. If an appropriate binary package already exists, no action is taken. If not, this target will compile, install and package it (and its depends, if PKG_DEPENDS is set properly. See ). After creating the binary package, the sources, the just-installed package and its required packages are removed, preserving free disk space. Beware that this target may deinstall all packages installed on a system! bulk-install Used during bulk-installs to install required packages. If an up-to-date binary package is available, it will be installed via &man.pkg.add.1;. If not, make bulk-package will be executed, but the installed binary won't be removed. A binary package is considered up-to-date to be installed via &man.pkg.add.1; if: None of the package's files (Makefile, ...) were modified since it was built. None of the package's required (binary) packages were modified since it was built. Beware that this target may deinstall all packages installed on a system! @ 1.81 log @doc/guide: remove documentation of WRAPPER_TRANSFORM_CMDS It is not used anymore. @ text @d1 1 a1 1 d397 4 a400 6 By default &man.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. @ 1.80 log @doc/guide: migrate from http to https @ text @d1 1 a1 1 a453 13 WRAPPER_TRANSFORM_CMDS A list of transformation commands. [TODO: investigate further] @ 1.79 log @doc/guide: fill in the MASTER_SITE variables automatically Keeping these two lists in sync is not something that humans should do. @ text @d1 1 a1 1 d213 2 a214 2 http://www.somewhere.com/somehow/ \ http://www.somewhereelse.com/mirror/somehow/ d228 1 a228 1 MASTER_SITES= http://www.example.com/download.cgi?file= d244 1 a244 1 MASTER_SITES= -http://www.example.com/archive/v1.0.0.tar.gz @ 1.78 log @Delete reference to EVAL_PREFIX, it was removed in November 2015. Pointed out by and in pkgsrc-users@@ @ text @d1 1 a1 1 d252 1 a252 35 ${MASTER_SITE_APACHE} ${MASTER_SITE_BACKUP} ${MASTER_SITE_CYGWIN} ${MASTER_SITE_DEBIAN} ${MASTER_SITE_FREEBSD} ${MASTER_SITE_FREEBSD_LOCAL} ${MASTER_SITE_GENTOO} ${MASTER_SITE_GNOME} ${MASTER_SITE_GNU} ${MASTER_SITE_GNUSTEP} ${MASTER_SITE_HASKELL_HACKAGE} ${MASTER_SITE_IFARCHIVE} ${MASTER_SITE_KDE} ${MASTER_SITE_MOZILLA} ${MASTER_SITE_MOZILLA_ALL} ${MASTER_SITE_MOZILLA_ESR} ${MASTER_SITE_MYSQL} ${MASTER_SITE_NETLIB} ${MASTER_SITE_OPENOFFICE} ${MASTER_SITE_OSDN} ${MASTER_SITE_PERL_CPAN} ${MASTER_SITE_PGSQL} ${MASTER_SITE_RUBYGEMS} ${MASTER_SITE_R_CRAN} ${MASTER_SITE_SOURCEFORGE} ${MASTER_SITE_SUNSITE} ${MASTER_SITE_SUSE} ${MASTER_SITE_TEX_CTAN} ${MASTER_SITE_XCONTRIB} ${MASTER_SITE_XEMACS} ${MASTER_SITE_XORG} @ 1.77 log @mention INSTALL_UNSTRIPPED @ text @d1 1 a1 1 a90 35 To determine the prefix of an installed package, the EVAL_PREFIX definition can be used. It takes pairs in the format DIRNAME=<package>, and the &man.make.1; variable DIRNAME will be set to the prefix of the installed package <package>, or ${PREFIX} if the package is not installed. This is best illustrated by example. The following lines are taken from pkgsrc/wm/scwm/Makefile: EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} CONFIGURE_ARGS+= --enable-multibyte Specific defaults can be defined for the packages evaluated using EVAL_PREFIX, by using a definition of the form: GTKDIR_DEFAULT= ${LOCALBASE} where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair. @ 1.76 log @Improve documentation regarding installation of games containing scorefiles. o Add an example that illustrates how to handle scorefiles and setgid games. o Document INSTALL_GAME_DIR. o Document GAMEDIR_PERMS, GAMEDATA_PERMS and SETGID_GAMES_PERMS and show how they can be used. Discussed with wiz@@. @ text @d1 1 a1 1 d746 7 @ 1.75 log @Add back . @ text @d1 1 a1 1 d712 4 @ 1.74 log @Remove USE_X11BASE and X11PREFIX from the documentation. @ text @d1 1 a1 1 d91 1 a91 1 To determine the prefix of an @ 1.73 log @Rename MASTER_SITE_SOURCEFORGE_JP to MASTER_SITE_OSDN. sourceforge.jp is renamed to osdn.jp. However its mirror sites are not ready for osdn.jp. @ text @d1 1 a1 1 d85 2 a86 2 X11-based packages are special in that they may be installed in either X11BASE or a87 33 Usually, X11 packages should be installed under LOCALBASE whenever possible. Note that you will need to include ../../mk/x11.buildlink3.mk in them to request the presence of X11 and to get the right compilation flags. Even though, there are some packages that cannot be installed under LOCALBASE: those that come with app-defaults files. These packages are special and they must be placed under X11BASE. To accomplish this, set either USE_X11BASE or USE_IMAKE in your package. Some notes: If you need to find includes or libraries installed by a pkg that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default. X11PREFIX should be used to refer to the installed location of an X11 package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed, and to LOCALBASE if xpkgwedge is installed. d91 1 a91 3 If xpkgwedge is installed, it is possible to have some packages installed in X11BASE and some in LOCALBASE. To determine the prefix of an d97 1 a97 1 ${X11PREFIX} if the package is not d587 2 a588 4 yes. (If you only want the package installed in ${X11PREFIX} but xmkmf not being run, set USE_X11BASE instead.) You can add variables to xmkmf's environment by adding them to the @ 1.72 log @Document install-clean, build-clean, print-build-depends-list and print-run-depends-list. The former two are from a recent mail on tech-pkg (obache@@, I believe), the latter two are from PR pkg/23035 (which was filed in 2003, oh my). @ text @d1 1 a1 1 d344 1 a349 1 ${MASTER_SITE_SOURCEFORGE_JP} @ 1.71 log @Fix dangling references after old bulk build setup removal. Place to-do markers to revisit it. @ text @d1 1 a1 1 d927 20 d1276 18 @ 1.70 log @change example URL to be matched as described in above. @ text @d1 1 a1 1 d1294 1 d1302 1 a1302 1 properly. See ). @ 1.69 log @Improve previous. @ text @d1 1 a1 1 d314 1 a314 1 MASTER_SITES= -http://www.example.com/archive/v1.0.0 @ 1.68 log @Update pre-defined MASTER_SITE_* list from sites.mk,v 1.104. @ text @d1 1 a1 1 d302 9 a310 6 In that case the URL is taken as is, fetched and the result stored under the name of the distfile. You can use this style for the case download URL style does not match to above usuall case. For example, permanent download URL is a redirecter to real download URL, or download file name is offerd by HTTP Content-Disposition header. d313 1 @ 1.67 log @describle for what MASTER_SITES starting with dash is used. @ text @d1 1 a1 1 d331 1 d335 2 d338 1 d342 1 d351 1 @ 1.66 log @and use DEFAULT_DISTFILES in examples too. @ text @d1 1 a1 1 d303 9 a311 1 under the name of the distfile. @ 1.65 log @mention to DEFAULT_DISTFILES. @ text @d1 1 a1 1 d266 1 a266 1 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz @ 1.64 log @Describe what to do with Makefile.PL. From Silas Silva in PR 46981. @ text @d1 1 a1 1 d255 2 a256 1 defaults to ${DISTNAME}${EXTRACT_SUFX}, @ 1.63 log @fix path of 'distfiles' directory on ftp.NetBSD.org @ text @d1 1 a1 1 d593 7 @ 1.62 log @/pub/NetBSD/packages/ on ftp.NetBSD.org is deprecated and not writable @ text @d1 1 a1 1 d342 1 a342 1 url="ftp://ftp.NetBSD.org/pkgsrc/distfiles/${DIST_SUBDIR}" @ 1.61 log @Add a note about URLs starting with a dash. @ text @d1 1 a1 1 d342 1 a342 1 url="ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}" d345 1 a345 1 url="ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/LOCAL_PORTS/" @ 1.60 log @Remove references to NO_PACKAGE, IGNORE and NO_CDROM from documentation. @ text @d1 1 a1 1 d300 4 @ 1.59 log @Spelling fixes. @ text @d1 1 a1 1 a780 6 If there should be no binary package, set NO_PACKAGE to yes. This should only be used in rare cases, like when a package definitely is only usable on the machine where it is built and even then, a binary package can be useful. @ 1.58 log @add missing xml-tag @ text @d1 1 a1 1 d13 1 a13 1 described in the following sections. Each phase is splitted into @ 1.57 log @Update for FETCH_USING changes. @ text @d1 1 a1 1 d387 1 a387 1 for FETCH_USING=custom. @ 1.56 log @CREATE_WRKDIR_SYMLINK is now default "no". @ text @d1 1 a1 1 d385 4 @ 1.55 log @Fix XML. @ text @d1 1 a1 1 d216 1 a216 1 to yes. It indicates whether a symbolic link to the @ 1.54 log @fix typo @ text @d1 1 a1 1 d221 1 a221 1 no. @ 1.53 log @Fix a typo, and remove information that will get outdated soon. @ text @d1 1 a1 1 d217 1 a217 1 WRKDIR is to be created in the pksrc entry's directory. @ 1.52 log @Document CREATE_WRKDIR_SYMLINK, prompted by Tobias Nygren. @ text @d1 1 a1 1 d218 4 a221 4 Historically, the symbolic link was created by default, and this value has now been restored to be the default. If users would like to have their pkgsrc trees behave in a read-only manner, then the value of CREATE_WRKDIR_SYMLINK shout be set to no. @ 1.51 log @fix broken xml tag @ text @d1 1 a1 1 d172 1 a172 1 When building a package, a number of directories is used to store d213 9 @ 1.50 log @Fix my speling as noticed by OKANO Takayoshi. @ text @d1 1 a1 1 d426 1 a426 1 bsdtargtar, nbtar @ 1.49 log @Document that bsdtar is a valid choice for EXTRACT_USING and that it is prefered over gtar (as it can be built out-of-the-box). @ text @d1 1 a1 1 d429 1 a429 1 archives should be extracted. It is prefered to choose bsdtar over gtar @ 1.48 log @Document USE_CMAKE. @ text @d1 1 a1 1 d426 2 a427 2 gtar, nbtar (which is the default value), pax, or an d429 2 a430 2 archives should be extracted. @ 1.47 log @Made all references to mk.conf consistent by defining and using a macro for it. Suggested by joerg. @ text @d1 1 a1 1 d585 10 @ 1.46 log @Changed all environments so that the first relevant column starts in column 1. Everything else is left to the style sheet. @ text @d1 1 a1 1 d912 1 a912 1 command line or in /etc/mk.conf to d1015 2 a1016 3 command line or in /etc/mk.conf to alter the behaviour of make clean-update: d1215 1 a1215 2 if PKG_DEVELOPER is set in /etc/mk.conf. @ 1.45 log @Update guide to reflect the changes with NO_MTREE/USE_MTREE. @ text @d1 1 a1 1 d140 6 a145 6 EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} CONFIGURE_ARGS+= --enable-multibyte d151 3 a153 3 GTKDIR_DEFAULT= ${LOCALBASE} d255 3 a257 3 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz d269 7 a275 7 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} DISTFILES+= foo-file.tar.gz SITES.foo-file.tar.gz= \ http://www.somewhere.com/somehow/ \ http://www.somewhereelse.com/mirror/somehow/ d287 3 a289 3 MASTER_SITES= http://www.example.com/download.cgi?file= d298 27 a324 27 ${MASTER_SITE_APACHE} ${MASTER_SITE_BACKUP} ${MASTER_SITE_CYGWIN} ${MASTER_SITE_DEBIAN} ${MASTER_SITE_FREEBSD} ${MASTER_SITE_FREEBSD_LOCAL} ${MASTER_SITE_GENTOO} ${MASTER_SITE_GNOME} ${MASTER_SITE_GNU} ${MASTER_SITE_GNUSTEP} ${MASTER_SITE_IFARCHIVE} ${MASTER_SITE_KDE} ${MASTER_SITE_MOZILLA} ${MASTER_SITE_MYSQL} ${MASTER_SITE_OPENOFFICE} ${MASTER_SITE_PERL_CPAN} ${MASTER_SITE_PGSQL} ${MASTER_SITE_R_CRAN} ${MASTER_SITE_SOURCEFORGE} ${MASTER_SITE_SOURCEFORGE_JP} ${MASTER_SITE_SUNSITE} ${MASTER_SITE_SUSE} ${MASTER_SITE_TEX_CTAN} ${MASTER_SITE_XCONTRIB} ${MASTER_SITE_XEMACS} d341 4 a344 4 MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/} MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/} d359 3 a361 3 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} d556 7 a562 6 .for d in ${CONFIGURE_DIRS} cd ${WRKSRC} && cd ${d} && env ${CONFIGURE_ENV} \ ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS} .endfor d595 10 a604 7 .for d in ${BUILD_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ -f ${MAKE_FILE} ${BUILD_TARGET} .endfor d648 10 a657 7 .for d in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ -f ${MAKE_FILE} ${BUILD_TARGET} .endfor @ 1.44 log @NO_BUILD is for build phase, not for configure phase @ text @d1 1 a1 1 d723 4 a726 10 beginning of the install phase. If this variable is set, NO_MTREE=yes is assumed, which means that the package claims to create all needed directories itself before installing files to it. Therefore this variable should only be set in Makefiles that are under control of the package's author. The directories are created with the correct ownership, depending on their name. @ 1.43 log @Document PKG_VERBOSE, PATCH_DEBUG, that one should not override foo but do-foo, mirror-distfiles, SCRIPTS_ENV, NO_CONFIGURE, NO_BUILD, NO_INSTALL, and NO_PACKAGE. @ text @d1 1 a1 1 d621 1 a621 1 If there is no configure step at all, set @ 1.42 log @Remove trailing spaces and tabs. @ text @d1 1 a1 1 d20 4 d31 4 d189 4 d375 7 d580 3 a582 1 USE_X11BASE instead.) d584 2 d621 2 d735 5 d757 6 @ 1.41 log @document ${MASTER_SITE_GENTOO}, from OKANO Takayoshi per PM @ text @d1 1 a1 1 d264 1 a264 1 d663 1 a663 1 d667 1 a667 1 d671 1 a671 1 d675 1 a675 1 d679 1 a679 1 d682 1 a682 1 @ 1.40 log @remove extra ")" @ text @d1 1 a1 1 d293 1 @ 1.39 log @- fix URL syntax: colon must be used with port number - fix path to pkgtools/pkg_tarup package approved by yyamano@@ @ text @d1 1 a1 1 d342 1 a342 1 (DISTDIR), which can be set by the pkgsrc @ 1.38 log @Fix typo and sync with the real. Patch provided by kano@@. @ text @d1 1 a1 1 d316 1 a316 1 url="ftp://ftp.NetBSD.org:/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}" d319 1 a319 1 url="ftp://ftp.NetBSD.org:/pub/NetBSD/packages/distfiles/LOCAL_PORTS/" d1008 1 a1008 1 role="pkg">pkgsrc/pkgtools/pkg_tarup for this @ 1.37 log @updated possible EXTRACT_USING values @ text @d1 1 a1 1 d188 1 a188 1 where all work takes place. The distfiles are extraced to this d392 1 a392 1 program, mk/scripts/extract, which d402 1 a402 1 mk/scripts/extract. @ 1.36 log @Add documentation for MASTER_SORT_RANDOM variable. @ text @d1 1 a1 1 d406 2 a407 1 pax, tar or an @ 1.35 log @Improve markup. Describe MASTER_SITE_BACKUP and MASTER_SITE_LOCAL. Document NO_INSTALL_MANPAGES. Describe "The package phase". Add section about "Cleaning up". Document DEPENDS_TARGET. Document the bin-install target. Improve UPDATE_TARGET description. Use &rprompt; and &cprompt; instead of .. Document replace and index targets. Reindent and break lines for 80 characters. @ text @d1 1 a1 1 d357 4 a360 2 all except the first can be optionally sorted by the user, via setting either MASTER_SORT_AWK or @ 1.34 log @It seems that the contents of should start in the first column for consistency. Make it so. @ text @d1 1 a1 1 d40 1 a40 1 for pkgs in the cross category. The value of d52 4 a55 3 PREFIX always points to the location where the current pkg will be installed. When referring to a pkg's own installation path, use ${PREFIX}. d59 4 a62 4 LOCALBASE is where all non-X11 pkgs are installed. If you need to construct a -I or -L argument to the compiler to find includes and libraries installed by another non-X11 pkg, use ${LOCALBASE}. The name d70 4 a73 4 X11BASE is where the actual X11 distribution (from xsrc, etc.) is installed. When looking for standard X11 includes (not those installed by a pkg), use ${X11BASE}. d77 3 a79 2 X11-based packages are special in that they may be installed in either X11BASE or LOCALBASE. d82 5 a86 4 LOCALBASE whenever possible. Note that you will need to include ../../mk/x11.buildlink3.mk in them to request the presence of X11 and to get the right compilation flags. d107 6 a112 4 X11PREFIX should be used to refer to the installed location of an X11 package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed, and to LOCALBASE if xpkgwedge is installed. d116 10 a125 8 If xpkgwedge is installed, it is possible to have some packages installed in X11BASE and some in LOCALBASE. To determine the prefix of an installed package, the EVAL_PREFIX definition can be used. It takes pairs in the format DIRNAME=<package>, and the &man.make.1; variable DIRNAME will be set to the prefix of the installed package <package>, or ${X11PREFIX} if the package is not installed. d139 3 a141 2 Specific defaults can be defined for the packages evaluated using EVAL_PREFIX, by using a definition of the form: d218 143 a360 440 The first step in building a package is to fetch the distribution files (distfiles) from the sites that are providing them. This is the task of the fetch phase. What to fetch and where to get it from In simple cases, MASTER_SITES defines all URLs from where the distfile, whose name is derived from the DISTNAME variable, is fetched. The more complicated cases are described below. The variable DISTFILES specifies the list of distfiles that have to be fetched. Its value defaults to ${DISTNAME}${EXTRACT_SUFX}, so that most packages don't need to define it at all. EXTRACT_SUFX is .tar.gz by default, but can be changed freely. Note that if your package requires additional distfiles to the default one, you cannot just append the additional filenames using the += operator, but you have write for example: DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz Each of the distfiles is fetched from a list of sites, usually MASTER_SITES. If the package has multiple DISTFILES or multiple PATCHFILES from different sites, you can set SITES.distfile to the list of URLs where the file distfile (including the suffix) can be found. DISTFILES= ${DISTNAME}${EXTRACT_SUFX} DISTFILES+= foo-file.tar.gz SITES.foo-file.tar.gz= \ http://www.somewhere.com/somehow/ \ http://www.somewhereelse.com/mirror/somehow/ When actually fetching the distfiles, each item from MASTER_SITES or SITES.* gets the name of each distfile appended to it, without an intermediate slash. Therefore, all site values have to end with a slash or other separator character. This allows for example to set MASTER_SITES to a URL of a CGI script that gets the name of the distfile as a parameter. In this case, the definition would look like: MASTER_SITES= http://www.example.com/download.cgi?file= There are some predefined values for MASTER_SITES, which can be used in packages. The names of the variables should speak for themselves. ${MASTER_SITE_APACHE} ${MASTER_SITE_BACKUP} ${MASTER_SITE_CYGWIN} ${MASTER_SITE_DEBIAN} ${MASTER_SITE_FREEBSD} ${MASTER_SITE_FREEBSD_LOCAL} ${MASTER_SITE_GNOME} ${MASTER_SITE_GNU} ${MASTER_SITE_GNUSTEP} ${MASTER_SITE_IFARCHIVE} ${MASTER_SITE_KDE} ${MASTER_SITE_MOZILLA} ${MASTER_SITE_MYSQL} ${MASTER_SITE_OPENOFFICE} ${MASTER_SITE_PERL_CPAN} ${MASTER_SITE_PGSQL} ${MASTER_SITE_R_CRAN} ${MASTER_SITE_SOURCEFORGE} ${MASTER_SITE_SOURCEFORGE_JP} ${MASTER_SITE_SUNSITE} ${MASTER_SITE_SUSE} ${MASTER_SITE_TEX_CTAN} ${MASTER_SITE_XCONTRIB} ${MASTER_SITE_XEMACS} If you choose one of these predefined sites, you may want to specify a subdirectory of that site. Since these macros may expand to more than one actual site, you must use the following construct to specify a subdirectory: MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/} MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/} Note the trailing slash after the subdirectory name. How are the files fetched? The fetch phase makes sure that all the distfiles exist in a local directory (DISTDIR), which can be set by the pkgsrc user). If the files do not exist, they are fetched 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. The <emphasis>checksum</emphasis> 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. The <emphasis>extract</emphasis> phase When the distfiles are present on the local system, they need to be extracted, as they usually come in the form of some compressed archive format. By default, all DISTFILES are extracted. If you only need some of them, you can set the EXTRACT_ONLY variable to the list of those files. Extracting the files is usually done by a little program, mk/scripts/extract, which already knows how to extract various archive formats, so most likely you will not need to change anything here. But if you need, the following variables may help you: EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO} Use these variables to override the default options for an extract command, which are defined in mk/scripts/extract. EXTRACT_USING This variable can be set to pax, tar or an absolute pathname pointing to the command with which tar archives should be extracted. If the extract program doesn't serve your needs, you can also override the EXTRACT_CMD variable, which holds the command used for extracting the files. This command is executed in the ${WRKSRC} directory. During execution of this command, the shell variable extract_file holds the absolute pathname of the file that is going to be extracted. And if that still does not suffice, you can override the do-extract target in the package Makefile. The <emphasis>patch</emphasis> 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 &man.patch.1; can be handed in PATCH_DIST_ARGS. See for more details. By default &man.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. The <emphasis>tools</emphasis> phase This is covered in . The <emphasis>wrapper</emphasis> phase This phase creates wrapper programs for the compilers and linkers. The following variables can be used to tweak the wrappers. ECHO_WRAPPER_MSG The command used to print progress messages. Does nothing by default. Set to ${ECHO} to see the progress messages. WRAPPER_DEBUG This variable can be set to yes (default) or no, depending on whether you want additional information in the wrapper log file. WRAPPER_UPDATE_CACHE This variable can be set to yes or no, depending on whether the wrapper should use its cache, which will improve the speed. The default value is yes, but is forced to no if the platform does not support it. WRAPPER_REORDER_CMDS A list of reordering commands. A reordering command has the form reorder:l:lib1:lib2. It ensures that that -llib1 occurs before -llib2. WRAPPER_TRANSFORM_CMDS A list of transformation commands. [TODO: investigate further] The <emphasis>configure</emphasis> 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.) The <emphasis>build</emphasis> 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 ${MAKE_FILE} ${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, MAKE_FILE 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 MAKE_FILE is Makefile, and BUILD_TARGET defaults to all. The <emphasis>test</emphasis> phase [TODO] The <emphasis>install</emphasis> 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. In the install phase, a rough equivalent of the following code is executed. Additionally, before and after this code, much magic is performed to do consistency checks, registering the package, and so on. .for d in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ -f ${MAKE_FILE} ${BUILD_TARGET} .endfor The variable's meanings are analogous to the ones in the build phase. INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is install by default, plus install.man if USE_IMAKE is defined. In the install phase, the following variables are useful. They are all variations of the &man.install.1; command that have the owner, group and permissions preset. INSTALL is the plain install command. The specialized variants, together with their intended use, are: INSTALL_PROGRAM_DIR directories that contain binaries INSTALL_SCRIPT_DIR directories that contain scripts INSTALL_LIB_DIR directories that contain shared and static libraries INSTALL_DATA_DIR directories that contain data files INSTALL_MAN_DIR directories that contain man pages INSTALL_PROGRAM binaries that can be stripped from debugging symbols INSTALL_SCRIPT binaries that cannot be stripped INSTALL_GAME game binaries INSTALL_LIB shared and static libraries INSTALL_DATA data files INSTALL_GAME_DATA data files for games INSTALL_MAN man pages Some other variables are: INSTALLATION_DIRS A list of directories relative to PREFIX that are created by pkgsrc at the beginning of the install phase. If this variable is set, NO_MTREE=yes is assumed, which means that the package claims to create all needed directories itself before installing files to it. Therefore this variable should only be set in Makefiles that are under control of the package's author. The directories are created with the correct ownership, depending on their name. d362 231 a592 1 d594 6 d603 105 d711 16 a726 1 [TODO] d728 4 d742 2 a743 2 For any of the main targets described in the previous section, two auxiliary targets exist with d746 5 a750 4 invoked before and after the main target is called, allowing extra configuration or installation steps be performed from a package's Makefile, for example, which a program's configure script or install target omitted. d758 7 a764 6 Should one of the main targets do the wrong thing, and should there be no variable to fix this, you can redefine it with the do-* target. (Note that redefining the target itself instead of the do-* target is a bad idea, as the pre-* and post-* targets won't be called anymore, etc.) You will not usually need to do this. d772 11 a782 4 If you did a make install and you noticed some file was not installed properly, you can repeat the installation with this target, which will ignore the already installed flag. d790 4 a793 3 This target does a &man.pkg.delete.1; in the current directory, effectively de-installing the package. The following variables can be used to tune the behaviour: d808 4 a811 3 Remove all packages that require (depend on) the given package. This can be used to remove any packages that may have been pulled in by a given package, e.g. if make deinstall d813 4 a816 2 pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding -R to the &man.pkg.delete.1; command line. d824 15 d842 32 a873 24 This target causes the current package to be updated to the latest version. The package and all depending packages first get de-installed, then current versions of the corresponding packages get compiled and installed. This is similar to manually noting which packages are currently installed, then performing a series of make deinstall and make install (or whatever UPDATE_TARGET is set to) for these packages. You can use the update target to resume package updating in case a previous make update was interrupted for some reason. However, in this case, make sure you don't call make clean or otherwise remove the list of dependent packages in WRKDIR. Otherwise, you lose the ability to automatically update the current package along with the dependent packages you have installed. Resuming an interrupted make update will only work as long as the package tree remains unchanged. If the source code for one of the packages to be updated has been changed, resuming make update will most certainly fail! The following variables can be used either on the command line or in /etc/mk.conf to alter the behaviour of make update: d880 9 a888 4 Install target to recursively use for the updated package and the dependent packages. Defaults to DEPENDS_TARGET if set, install otherwise for make update. e.g. make update UPDATE_TARGET=package d896 9 a904 6 Don't clean up after updating. Useful if you want to leave the work sources of the updated packages around for inspection or other purposes. Be sure you eventually clean up the source tree (see the clean-update target below) or you may run into troubles with old source code still lying around on your next make or make update. d912 6 a917 4 Deinstall each package before installing (making DEPENDS_TARGET). This may be necessary if the clean-update target (see below) was called after interrupting a running make update. d925 11 a935 7 Allows you to disable recursion and hardcode the target for packages. The default is update for the update target, facilitating a recursive update of prerequisite packages. Only set DEPENDS_TARGET if you want to disable recursive updates. Use UPDATE_TARGET instead to just set a specific target for each package to be installed during make update (see above). d946 20 a965 16 Clean the source tree for all packages that would get updated if make update was called from the current directory. This target should not be used if the current package (or any of its depending packages) have already been de-installed (e.g., after calling make update) or you may lose some packages you intended to update. As a rule of thumb: only use this target before the first time you run make update and only if you have a dirty package tree (e.g., if you used NOCLEAN). If you are unsure about whether your tree is clean, you can either perform a make clean at the top of the tree, or use the following sequence of commands from the directory of the package you want to update (before running make update for the first time, otherwise you lose all the packages you wanted to update!): d968 3 a970 3 # make clean-update # make clean CLEANDEPENDS=YES # make update d973 4 a976 3 The following variables can be used either on the command line or in /etc/mk.conf to alter the behaviour of make clean-update: d983 9 a991 6 After make clean, do not reconstruct the list of directories to update for this package. Only use this if make update successfully installed all packages you wanted to update. Normally, this is done automatically on make update, but may have been suppressed by the NOCLEAN variable (see above). d999 21 d1024 27 a1050 2 package. You can use this to check which version of a package is installed. d1054 1 d1059 22 a1080 16 This target generates a README.html file, which can be viewed using a browser such as www/firefox or www/links. The generated files contain references to any packages which are in the PACKAGES directory on the local host. The generated files can be made to refer to URLs based on FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate README.html files which pointed to binary packages on the local machine, in the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its subdirectories will be searched for all the binary packages. d1088 9 a1096 6 Use this target to create a file README-all.html which contains a list of all packages currently available in the &os; Packages Collection, together with the category they belong to and a short description. This file is compiled from the pkgsrc/*/README.html files, so be sure to run this after a make readme. d1104 7 a1110 5 This is very much the same as the readme target (see above), but is to be used when generating a pkgsrc tree to be written to a CD-ROM. This target also produces README.html files, and can be made to refer to URLs based on CDROM_PKG_URL_HOST and d1119 4 a1122 3 This target shows which distfiles and patchfiles are needed to build the package (ALLFILES, which contains all DISTFILES and d1132 7 a1138 5 This target shows nothing if the package is not installed. If a version of this package is installed, but is not the version provided in this version of pkgsrc, then a warning message is displayed. This target can be used to show which of your installed packages are downlevel, and so the old versions can be deleted, and the current ones added. d1146 7 a1152 5 This target shows the directory in the pkgsrc hierarchy from which the package can be built and installed. This may not be the same directory as the one from which the package was installed. This target is intended to be used by people who may wish to upgrade many packages on a single host, and can be invoked from the top-level pkgsrc Makefile by using the d1161 4 a1164 3 This target shows which installed packages match the current package's DEPENDS. Useful if out of date dependencies are causing build problems. d1172 4 a1175 3 After a package is installed, check all its binaries and (on ELF platforms) shared libraries to see if they find the shared libs they need. Run by default if PKG_DEVELOPER is set in d1185 4 a1188 4 upgraded pkg, this prints out an attempt to generate a new PLIST from a find -newer work/.extract_done. An attempt is made to care for shared libs etc., but it is d1195 3 a1197 3 If the package installs files via &man.tar.1; or other methods that don't update file access times, be sure to add these files manually to your d1211 8 a1218 7 Used to do bulk builds. If an appropriate binary package already exists, no action is taken. If not, this target will compile, install and package it (and its depends, if PKG_DEPENDS is set properly. See ). After creating the binary package, the sources, the just-installed package and its required packages are removed, preserving free disk space. d1220 2 a1221 2 Beware that this target may deinstall all packages installed on a system! d1229 4 a1232 3 Used during bulk-installs to install required packages. If an up-to-date binary package is available, it will be installed via &man.pkg.add.1;. If not, make bulk-package will be executed, d1235 3 a1237 2 A binary package is considered up-to-date to be installed via &man.pkg.add.1; if: d1241 3 a1243 2 None of the package's files (Makefile, ...) were modified since it was built. d1247 2 a1248 2 None of the package's required (binary) packages were modified since it was built. d1252 2 a1253 2 Beware that this target may deinstall all packages installed on a system! @ 1.33 log @Document ALLFILES, reindent a bit. @ text @d1 1 a1 1 d842 5 a846 3 # make clean-update # make clean CLEANDEPENDS=YES # make update @ 1.32 log @Rename variable MAKEFILE to MAKE_FILE. @ text @d1 1 a1 1 d4 1 a4 1 The build process d6 2 a7 2 Introduction d9 17 a25 17 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 phase, 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 any pkgsrc-specific patches to compile properly 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. d27 1 a27 1 d33 2 a34 2 the next section, here's a brief discussion on where programs are installed, and which variables influence this. d37 9 a45 9 where all files of the final program shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for pkgs in the cross category. The value of PREFIX needs to be put into the various places in the program's source where paths to these files are encoded. See and for more details. d48 1 a48 1 follow the following rules: d53 2 a54 2 pkg will be installed. When referring to a pkg's own installation path, use ${PREFIX}. d59 7 a65 7 If you need to construct a -I or -L argument to the compiler to find includes and libraries installed by another non-X11 pkg, use ${LOCALBASE}. The name LOCALBASE stems from FreeBSD, which installed all packages in /usr/local. As pkgsrc leaves /usr/local for the system administrator, this variable is a misnomer. d70 3 a72 3 xsrc, etc.) is installed. When looking for standard X11 includes (not those installed by a pkg), use ${X11BASE}. d77 1 a77 1 either X11BASE or LOCALBASE. d80 4 a83 4 LOCALBASE whenever possible. Note that you will need to include ../../mk/x11.buildlink3.mk in them to request the presence of X11 and to get the right compilation flags. d86 5 a90 5 under LOCALBASE: those that come with app-defaults files. These packages are special and they must be placed under X11BASE. To accomplish this, set either USE_X11BASE or USE_IMAKE in your package. d93 8 a100 8 to find includes or libraries installed by a pkg that has USE_IMAKE or USE_X11BASE in its pkg Makefile, you need to look in both ${X11BASE} and ${LOCALBASE}. To force installation of all X11 packages in LOCALBASE, the pkgtools/xpkgwedge package is enabled by default. d105 3 a107 3 location of an X11 package. X11PREFIX will be set to X11BASE if xpkgwedge is not installed, and to LOCALBASE if xpkgwedge is installed. d112 7 a118 7 in X11BASE and some in LOCALBASE. To determine the prefix of an installed package, the EVAL_PREFIX definition can be used. It takes pairs in the format DIRNAME=<package>, and the &man.make.1; variable DIRNAME will be set to the prefix of the installed package <package>, or ${X11PREFIX} if the package is not installed. d123 1 a123 1 pkgsrc/wm/scwm/Makefile: d125 6 a130 6 EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} CONFIGURE_ARGS+= --enable-multibyte d133 1 a133 1 EVAL_PREFIX, by using a definition of the form: d135 3 a137 3 GTKDIR_DEFAULT= ${LOCALBASE} d140 2 a141 2 to the first definition in the EVAL_PREFIX pair. d145 4 a148 4 Within ${PREFIX}, packages should install files according to &man.hier.7;, with the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/man. d153 12 a164 2 Directories used during the build process d166 1 a166 35 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. PKGSRCDIR This is an absolute pathname that points to the pkgsrc root directory. Generally, you don't need it. PKGPATH This is a pathname relative to PKGSRCDIR that points to the current package. WRKDIR This is an absolute pathname pointing to the directory where all work takes place. The distfiles are extraced to this directory. It also contains temporary directories and log files used by the various pkgsrc frameworks, like buildlink or the wrappers. WRKSRC 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. This variable may be changed by a package Makefile. d168 26 a193 2 d195 2 a196 2 Running a phase d198 6 a203 6 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. d205 1 a205 1 d207 2 a208 2 The <emphasis>fetch</emphasis> phase d510 1 a510 1 cd ${WRKSRC} && cd ${d} && env ${CONFIGURE_ENV} \ d541 1 a541 1 cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ d585 1 a585 1 cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ d654 1 a654 1 d656 2 a657 2 The <emphasis>package</emphasis> phase d659 1 a659 1 [TODO] d661 1 a661 1 d671 8 a678 8 For any of the main targets described in the previous section, two auxiliary targets exist with pre- and post- used as a prefix for the main target's name. These targets are invoked before and after the main target is called, allowing extra configuration or installation steps be performed from a package's Makefile, for example, which a program's configure script or install target omitted. d686 6 a691 5 Should one of the main targets do the wrong thing, and should there be no variable to fix this, you can redefine it with the do-* target. (Note that redefining the target itself instead of the do-* target is a bad idea, as the pre-* and post-* targets won't be called anymore, etc.) You will not usually need to do this. d699 4 a702 3 If you did a make install and you noticed some file was not installed properly, you can repeat the installation with this target, which will ignore the already installed flag. d711 2 a712 2 effectively de-installing the package. The following variables can be used to tune the behaviour: d728 5 a732 5 This can be used to remove any packages that may have been pulled in by a given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding -R to the &man.pkg.delete.1; command line. d744 6 a749 6 version. The package and all depending packages first get de-installed, then current versions of the corresponding packages get compiled and installed. This is similar to manually noting which packages are currently installed, then performing a series of make deinstall and make install (or whatever UPDATE_TARGET is set to) for these packages. d752 6 a757 6 updating in case a previous make update was interrupted for some reason. However, in this case, make sure you don't call make clean or otherwise remove the list of dependent packages in WRKDIR. Otherwise, you lose the ability to automatically update the current package along with the dependent packages you have installed. d760 3 a762 3 long as the package tree remains unchanged. If the source code for one of the packages to be updated has been changed, resuming make update will most certainly fail! d765 2 a766 2 /etc/mk.conf to alter the behaviour of make update: d774 3 a776 3 dependent packages. Defaults to DEPENDS_TARGET if set, install otherwise for make update. e.g. make update UPDATE_TARGET=package d785 5 a789 5 work sources of the updated packages around for inspection or other purposes. Be sure you eventually clean up the source tree (see the clean-update target below) or you may run into troubles with old source code still lying around on your next make or make update. d798 3 a800 3 DEPENDS_TARGET). This may be necessary if the clean-update target (see below) was called after interrupting a running make update. d809 6 a814 6 packages. The default is update for the update target, facilitating a recursive update of prerequisite packages. Only set DEPENDS_TARGET if you want to disable recursive updates. Use UPDATE_TARGET instead to just set a specific target for each package to be installed during make update (see above). d826 8 a833 8 make update was called from the current directory. This target should not be used if the current package (or any of its depending packages) have already been de-installed (e.g., after calling make update) or you may lose some packages you intended to update. As a rule of thumb: only use this target before the first time you run make update and only if you have a dirty package tree (e.g., if you used NOCLEAN). d836 5 a840 5 perform a make clean at the top of the tree, or use the following sequence of commands from the directory of the package you want to update (before running make update for the first time, otherwise you lose all the packages you wanted to update!): d843 2 a844 2 # make clean CLEANDEPENDS=YES # make update d847 2 a848 2 /etc/mk.conf to alter the behaviour of make clean-update: d856 5 a860 5 directories to update for this package. Only use this if make update successfully installed all packages you wanted to update. Normally, this is done automatically on make update, but may have been suppressed by the NOCLEAN variable (see above). d872 2 a873 2 package. You can use this to check which version of a package is installed. d905 5 a909 5 which contains a list of all packages currently available in the &os; Packages Collection, together with the category they belong to and a short description. This file is compiled from the pkgsrc/*/README.html files, so be sure to run this after a make readme. d918 5 a922 5 above), but is to be used when generating a pkgsrc tree to be written to a CD-ROM. This target also produces README.html files, and can be made to refer to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR. d930 5 a934 3 This target shows which distfiles and patchfiles are needed to build the package. (DISTFILES and PATCHFILES, but not patches/*) d943 4 a946 4 of this package is installed, but is not the version provided in this version of pkgsrc, then a warning message is displayed. This target can be used to show which of your installed packages are downlevel, and so the old versions can be deleted, and the current ones added. d955 5 a959 5 package can be built and installed. This may not be the same directory as the one from which the package was installed. This target is intended to be used by people who may wish to upgrade many packages on a single host, and can be invoked from the top-level pkgsrc Makefile by using the show-host-specific-pkgs target. d968 2 a969 2 DEPENDS. Useful if out of date dependencies are causing build problems. d978 3 a980 3 platforms) shared libraries to see if they find the shared libs they need. Run by default if PKG_DEVELOPER is set in /etc/mk.conf. d989 9 a997 9 upgraded pkg, this prints out an attempt to generate a new PLIST from a find -newer work/.extract_done. An attempt is made to care for shared libs etc., but it is strongly recommended to review the result before putting it into PLIST. On upgrades, it's useful to diff the output of this command against an already existing PLIST file. d1000 5 a1004 5 methods that don't update file access times, be sure to add these files manually to your PLIST, as the find -newer command used by this target won't catch them! d1006 2 a1007 2 See for more information on this target. d1016 6 a1021 6 no action is taken. If not, this target will compile, install and package it (and its depends, if PKG_DEPENDS is set properly. See ). After creating the binary package, the sources, the just-installed package and its required packages are removed, preserving free disk space. d1024 1 a1024 1 packages installed on a system! d1033 3 a1035 3 up-to-date binary package is available, it will be installed via &man.pkg.add.1;. If not, make bulk-package will be executed, but the installed binary won't be removed. d1037 2 a1038 2 A binary package is considered up-to-date to be installed via &man.pkg.add.1; if: d1043 1 a1043 1 ...) were modified since it was built. d1048 1 a1048 1 modified since it was built. d1053 1 a1053 1 packages installed on a system! @ 1.31 log @Refer to firefox instead of mozilla. @ text @d1 1 a1 1 d543 1 a543 1 -f ${MAKEFILE} ${BUILD_TARGET} d553 1 a553 1 MAKEFILE and BUILD_TARGET may all d559 1 a559 1 of MAKEFILE is Makefile, and d587 1 a587 1 -f ${MAKEFILE} ${BUILD_TARGET} @ 1.30 log @Moved the explanation of the various variables in the "fetch" phase from components.xml to build.xml. Added a list of variable names and a link to the old place. Rewrote and extended the existing documentation to cover most common cases. @ text @d1 1 a1 1 d881 1 a881 1 www/mozilla or @ 1.29 log @Added a note that the name LOCALBASE stems from FreeBSD. @ text @d1 1 a1 1 d210 113 a322 6 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: d328 10 a337 9 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. d339 1 @ 1.28 log @INSTALLATION_DIRS creates directories with the correct ownership. @ text @d1 1 a1 1 d61 5 a65 1 ${LOCALBASE}. @ 1.27 log @Specified the structure and interpretation of the WRAPPER_REORDER_CMDS variable. @ text @d1 1 a1 1 d524 1 d527 2 a528 2 the beginning of the install phase. If this variable is set, d534 4 a537 1 the package's author. @ 1.26 log @Documented (parts of) the wrapper phase. @ text @d1 1 a1 5 d219 1 a219 1 specified in either SITES_file if defined, else d353 9 a361 2 A list of reordering commands. [TODO: investigate further] @ 1.25 log @After the 2006Q1 branch, SITES_${file} should be replaced with SITES.${file}. @ text @d1 1 a1 1 d328 44 a371 1 [TODO] d373 1 @ 1.24 log @Documented the new mk/scripts/extract command. @ text @d1 5 a5 1 @ 1.23 log @Removed trailing white-space. @ text @d1 1 a1 1 d123 3 a125 3 CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \ --with-gtk-prefix="${GTKDIR}" \ --enable-multibyte d244 42 a285 30 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: a286 6 EXTRACT_SUFX= .msg.gz EXTRACT_CMD= zcat EXTRACT_BEFORE_ARGS= EXTRACT_AFTER_ARGS= |sh @ 1.22 log @Added a description for INSTALLATION_DIRS. Reworded the text of the build.install section. @ text @d1 1 a1 1 d41 1 a41 1 PREFIX needs to be put d94 2 a95 2 all X11 packages in LOCALBASE, the pkgtools/xpkgwedge package d139 1 a139 1 d144 1 a144 1 ${PREFIX}/share/man. d390 1 a390 1 BUILD_TARGET defaults to all. d503 1 a503 1 example, which a program's configure script d706 1 a706 1 can be viewed using a browser such as d708 1 a708 1 www/links. @ 1.21 log @Cross reference the "tools phase" section to the new tools chapter. I removed the TODO here; maybe some text should still be added for this chapter? @ text @d1 1 a1 1 d406 22 a427 6 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). a436 4 d462 18 @ 1.20 log @s/unstripped/stripped/ @ text @d1 1 a1 1 d309 3 a311 1 [TODO] @ 1.19 log @[The ''install'' phase] Documented the various INSTALL_* variables. @ text @d1 1 a1 1 d436 1 a436 1 binaries that cannot be unstripped @ 1.18 log @Cleaned up a bit on the wording. @ text @d1 1 a1 1 d402 46 a447 9 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). @ 1.17 log @Note that the distfiles are extracted to WRKDIR. @ text @d1 1 a1 1 d15 1 a15 1 containing stage, prefixed by one of pre-, d20 6 a25 8 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 any patches to compile properly on &os; 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 &os; package system, which is implemented as a series of targets in a central Makefile, pkgsrc/mk/bsd.pkg.mk. d160 1 a160 2 inside the package itself. The permissions after each variable indicate whether the variable may be changed by the package Makefile. d164 1 a164 1 PKGSRCDIR (read-only) d169 1 a169 1 PKGPATH (read-only) d174 1 a174 1 WRKDIR (read-only) d181 1 a181 1 WRKSRC (read-write) d185 2 a186 1 that isn't hidden. @ 1.16 log @Added the default value of CONFIGURE_DIRS. Rewrote the ``build'' phase description to have the same structure as the ``configure'' phase description. @ text @d1 1 a1 1 d179 4 a182 4 where all work takes place. This directory typically contains temporary directories used by the various pkgsrc frameworks, like buildlink or the wrappers. @ 1.15 log @Documented the use of CONFIGURE_DIRS, as pkglint has got a new error diagnostic that need this explanation. @ text @d1 1 a1 1 d345 9 a353 7 CONFIGURE_DIRS is a list of pathnames relative to WRKSRC. In each of these directories, the configure script is run with the same environment and arguments. The variables CONFIGURE_ENV, CONFIGURE_SCRIPT (default: ./configure) and CONFIGURE_ARGS may all be changed by the package. d366 25 a390 10 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. @ 1.14 log @Reformatted and improved the explanation of the directories. @ text @d1 1 a1 1 d325 12 a336 18 Most pieces of software need information on the header files, system calls, and library routines which are available in &os;. 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: d339 4 a342 3 HAS_CONFIGURE= yes CONFIGURE_SCRIPT= Configure CONFIGURE_ARGS+= netbsd13 d345 13 a357 5 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!) @ 1.13 log @Added explanations for some of the directories used in the build process. More will follow. @ text @d1 1 a1 1 d158 7 d167 8 a174 6 PKGSRCDIRThis is an absolute pathname that points to the pkgsrc root directory. Generally, you don't need it. PKGPATHThis is a pathname relative to PKGSRCDIR that points to the current d177 5 a181 4 WRKDIRThis 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 d184 5 a188 5 WRKSRCThis 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 doesn't start with a dot. @ 1.12 log @Wrote an introduction and converted the itemize list of main targets into sections. These sections are still very incomplete. @ text @d1 1 a1 1 d151 32 @ 1.11 log @Reindented all s. @ text @d1 1 a1 1 d4 15 a18 1 The build process d29 2 d151 9 a159 2 Main targets d161 1 a161 2 The main targets used during the build process defined in bsd.pkg.mk are: d163 2 a164 3 fetch a165 1 a185 2 d187 4 a190 2 checksum a191 1 a197 2 d199 4 a202 2 extract a203 1 a240 2 d242 4 a245 2 patch a246 1 a262 2 d264 18 a281 2 configure a282 1 a312 2 d314 4 a317 2 build a318 1 a328 2 d330 11 a340 2 install a341 1 a349 3 d351 6 a356 3 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: d358 1 a358 9 make fetch make checksum make extract make patch make configure make build @ 1.10 log @Various fixes for typos and grammar by Leonard Schmidt. @ text @d1 1 a1 1 d107 6 a112 4 EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \ --with-gtk-prefix="${GTKDIR}" \ --enable-multibyte d117 3 a119 1 GTKDIR_DEFAULT= ${LOCALBASE} d153 3 a155 1 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} d217 6 a222 4 EXTRACT_SUFX= .msg.gz EXTRACT_CMD= zcat EXTRACT_BEFORE_ARGS= EXTRACT_AFTER_ARGS= |sh d272 5 a276 3 HAS_CONFIGURE= yes CONFIGURE_SCRIPT= Configure CONFIGURE_ARGS+= netbsd13 d323 8 a330 7 make fetch make checksum make extract make patch make configure make build @ 1.9 log @Replace by as discussed on netbsd-docs@@. ok hubertf@@ @ text @d1 1 a1 1 d58 2 a59 2 X11 based are special in that they may be installed in either X11BASE or LOCALBASE. d205 2 a206 2 various DECOMPRESS_CMD variables bsd.pkg.mk for a complete d412 1 a412 1 packages in WRKDIR. Otherwise you lose the d492 4 a495 4 If you unsure about whether your tree is clean you can either perform a make clean at the top of the tree, or use the following sequence of commands from the directory of the package you want to update (before running d672 2 a673 2 package it (and it's depends, if PKG_DEPENDS is set properly. See . d675 1 a675 1 package, the sources, the just-installed package and it's required d688 1 a688 1 upto-date binary package is available, it will be installed via d690 1 a690 1 but the installed binary not be removed. d692 1 a692 1 A binary package is considered upto-date to be @ 1.8 log @Update guide for USE_X11 -> x11.buildlink3.mk change. @ text @d1 1 a1 1 d81 2 a82 1 pkgtools/xpkgwedge package is enabled by default. d262 1 a262 1 the sysutils/top package: d539 4 a542 2 can be viewed using a browser such as www/mozilla or www/links. The generated files contain references to any @ 1.7 log @Add an id to all sect[123]. @ text @d1 1 a1 1 d63 2 a64 1 need to set USE_X11 in them to request the d74 1 a74 2 Some notes: USE_X11 and USE_X11BASE are mutually exclusive. If you need d77 1 a77 1 its pkg Makefile, you need to use d81 1 a81 1 pkgtools/xpkgwedge is enabled by default. @ 1.6 log @Replaced obsoleted USE_GNU_TOOLS with USE_TOOLS. @ text @d1 1 a1 1 d130 1 a130 1 @ 1.5 log @Applied the "detab" tab->space conversion. @ text @d1 1 a1 1 d283 1 a283 1 gmake if USE_GNU_TOOLS contains make, @ 1.4 log @Use more man page entities, now that we have them. @ text @d1 1 a1 1 d106 4 a109 4 EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \ --with-gtk-prefix="${GTKDIR}" \ --enable-multibyte d114 1 a114 1 GTKDIR_DEFAULT= ${LOCALBASE} d148 1 a148 1 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} d210 1 a210 1 EXTRACT_SUFX= .msg.gz d263 1 a263 1 HAS_CONFIGURE= yes @ 1.3 log @ALL_TARGET -> BUILD_TARGET. @ text @d1 1 a1 1 d96 1 a96 1 format DIRNAME=<package>, and the make(1) variable d123 1 a123 1 install files according to hier(7), with the exception that d228 1 a228 1 .rej are ignored. Any special options to patch(1) d232 1 a232 1 By default patch(1) is given special args to make it fail if the d366 1 a366 1 This target does a pkg_delete(1) in the current directory, d651 1 a651 1 If the package installs files via tar(1) or other @ 1.2 log @Replace obsolete USE_GMAKE reference; noted by iMil on tech-pkg. @ text @d1 1 a1 1 d281 1 a281 1 $MAKEFILE with $ALL_TARGET as d285 1 a285 1 Makefile by default, and ALL_TARGET @ 1.1 log @Initial revision @ text @d1 1 a1 1 d283 1 a283 1 gmake if USE_GMAKE is set, @ 1.1.1.1 log @import The pkgsrc guide, the docbook conversion/replacement of Packages.txt; Packages.txt will be going away. this package contains the source files and a mechanism to install pkgsrc/doc/pkgsrc.{html,txt} which are distributed with pkgsrc. it uses the same docbook infrastructure that is used to build the documentation on www.NetBSD.org. @ text @@