8.2. Main targets

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, they will be fetched using ftp(1) from the site(s) given in the variable PATCH_SITES. The location(s) in PATCH_SITES are in the form of URLs and can be ftp://- and http://-URLs, as ftp(1) understands both of them.

After the distfile(s) are fetched, their MD5 checksum is generated and compared with the checksums stored in the files/md5 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.

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 EXTRACT_CMD, EXTRACT_BEFORE_ARGS and/or EXTRACT_AFTER_ARGS.

After extraction, all the patches named by the PATCHFILES and those present in the patches subdirectory of the package are applied. Patchfiles ending in .Z or .gz are uncompressed before they are applied, files ending in .orig or .rej are ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See patches/* for more details.

If the variable PKG_DEVELOPER is set in /etc/mk.conf, patch is given special args to make it fail if the patches with some lines of fuzz. Please fix (regenerate) the patches so that they apply cleanly. The rationale behind this is that patches that apply cleanly may end up being applied in the wrong place, and cause severe harm there.

Most pieces of software need information on the header files, system calls, and library routines which are available in NetBSD. This is the process known as configuration, and is usually automated. In most cases, a script is supplied with the source, and its invocation results in generation of header files, Makefiles, etc.

If the program doesn't come with its own configure script, one can be placed in the package's scripts directory, called configure. If so, it is executed using sh(1).

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.

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!)

Once configuration has taken place, the software can be built on NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as the target to build. The default MAKE_PROGRAM is ``gmake'' if USE_GMAKE is set, ``make'' otherwise. MAKEFILE is set to Makefile by default, and ALL_TARGET defaults to all. Any of these variables can be set to change the default build process.

Once the build stage has completed, the final step is to install the software in public directories, for users. 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).