Klaus Heinz wrote:
> There are various stages during the build of a package. Those stages
> are listed at the top of pkgsrc/mk/bsd.pkg.mk:
> 
>   # Default sequence for "all" is:
>   #
>   #    bootstrap-depends
>   #    fetch
>   #    checksum
>   #    depends
>   #    tools
>   #    extract
>   #    patch
>   #    wrapper
>   #    configure
>   #    build
> 
> (Note to self: we must describe the mechanism, if not all of the
> targets, in the pkgsrc guide).

something like http://www.netbsd.org/Documentation/pkgsrc/build.html?

> If the project at hand does the same, pkgsrc has to know about this
> and for this purpose there is the HAS_CONFIGURE variable, set to "yes"
> in many of the pkgsrc Makefiles. Now pkgsrc knows that is must go to
> the WRKSRC directory and start the "configure" program, _maybe_ using a
> shell if it is a script. There are many knobs (= variables) in pkgsrc
> to customize this configuration process further.

Since last month or so, it's not _maybe_, but _always_. Before, the 
CONFIG_SHELL had only been defined for GNU-style configure scripts.

>   - CONFIGURE_DIRS is usually the same as WRKSRC but can be set to a
>     different directory if the configure script lives in, say, the "src"
>     sub-directory of a software directory. Or it can even be a list
>     of directories, hence the .for ... .endfor loop.

And hence the name of the variable (_DIRS_, not _DIR_).

>   - You can influence the environment used during the run of the
>     "configure" script through CONFIGURE_ENV (hidden in the SETENV
>     variable above).

It's hidden in the _CONFIGURE_SCRIPT_ENV variable, not in SETENV.

> The first task in building a pkgsrc package for some software is
> determining which kind of build system it has, which knobs this
> system offers, looking whether and how pkgsrc already supports it and
> chasing down the various pkgsrc variables to control the run of that
> build system.

See also:
http://www.netbsd.org/Documentation/pkgsrc/devfaq.html#devfaq.documentation

Roland