Jan Danielsson wrote:

>    I'm having some trouble understanding where the line is drawn between
> pkgsrc and the packages own build system. I understand that pkgsrc does
> some preparations, then modifies the package's build system as required,
> then kicks it off. Once it's done, it returns to pkgsrc for installation
> or ever build target has been chosen. But how does it know which actions
> to take? Does it always assume that it should run:
> 
> configure --prefix=/usr/pkg

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

Since pkgsrc is centered around the concepts of "make", those listed
words are make "targets". If you do not know some basics about make I
recommend to look them up in the make(1) man page (or even Wikipedia).

"all" is traditionally the default target which make tries to find and
build if you simply type
  $ make
in a pkgsrc directory.

The meaning of the comment above is, that "all" depends on the other
targets, from "bootstrap-depends" to "build", in that order. So, if you
type "make", the program tries to "create" the target "all" and for this
purpose it tries to create "bootstrap-depends" (we ignore this for now),
then "fetch" (where the source archive file specified in the pkgsrc
Makefile is fetched), then "checksum" (where the checksums provided
in the distinfo file are recomputed and compared) and so on.
Every target listed has sub-targets it depends upon, and most of them
have sub-targets again. The chain of targets defines the work pkgsrc does.

Until the "configure" stage, everything is internal to pkgsrc, ie, the
build system of the software you are trying to build is not involved.

During the "configure" stage, pkgsrc has to tell the build system of
the software, well, to "configure" itself. As you noticed, many
software systems use the "./configure" command for this configuration.

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.
At the moment, what happens is this

  do-configure-script:
  .for _dir_ in ${CONFIGURE_DIRS}
        ${_PKG_SILENT}${_PKG_DEBUG}${_ULIMIT_CMD} \
        cd ${WRKSRC} && cd ${_dir_} && \
        ${SETENV} ${_CONFIGURE_SCRIPT_ENV} \
                ${CONFIG_SHELL} ${CONFIG_SHELL_FLAGS} \
                        ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
  .endfor
(taken from pkgsrc/mk/configure/configure.mk)

You may recognize some of those knobs/variables from pkgsrc Makefiles
you have seen. Many of them have default values:
  - CONFIG_SHELL is usually /bin/sh but you can set it to something else
    (eg, bash) if the configure script uses specific features of
    that shell.
  - some software packages do not call their script "configure", so you
    can tell pkgsrc the name, eg "myconfigurescript" through the
    variable CONFIGURE_SCRIPT.
  - 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.
  - You can influence the environment used during the run of the
    "configure" script through CONFIGURE_ENV (hidden in the SETENV
    variable above).
  - you can specify special options in CONFIGURE_ARGS (eg, --prefix,
    --with-feature-Z, -foo, -bar, ...)
  - ...

Once the configure script has finished, control returns to pkgsrc and
eventually the dance continues in a similar but also different way for
the next sub-target of "all", "build".

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.


ciao
     Klaus