Re: RFC: distbb for cross-compiling packages

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> So I would think that operations like

>   on a machine, cause cross tools to be built

>   on a machine, unpack a release set to form a destdir for use with
>   cross tools

> would be supported locally, with no distbb, and then you are saying that
> distbb would have support for running these on the remote helper
> machines so that one would be spared doing something N times?
No. Building packages in parallel using several hosts and/or chroots was
implemented years ago. With a help of DistBB you can run bulk builds
using several machines in local network or connected via Internet, or
just using a few local chroot environments. This has never been a
problem. DistBB has a lot of cool features absent in pbulk and bulk
build framework but I'm not willing to discuss them now.

Let me clarify again what I implemented during the last few days.

Steps you need to take for cross-compiling a package in pkgsrc.
1) Setup your build environment:

   A) Build cross-toolchain using 'build.sh -m' if you want to build the
   package for NetBSD, or manually if your target platform is not a
   NetBSD. As a result of this step you have a directory that contains
   a cross-toolchain.

   B) Unpack NetBSD sets (some of them actually) to some directory, or
   create such a directory manually if the target platform is not a
   NetBSD.

2) 
   Install *build-platform* and *target-platform* dependencies on your
   system. If, for example, the package wants to regenerate configure
   script, you'll need to install autoconf and probably automake
   packages to your system. The same for GNU make if the software
   requires it.

   PLEASE NOTE THAT IN PKGSRC DEPENDS_BUILDS DOESN'T SAY WHETHER
   A DEPENDENCY IS A BUILD-HOST DEPENDENCY OR TARGET-HOST DEPENDENCY.

        PKGNAME:        dict-mueller7-1.2
        PKGPATH:        textproc/dict-mueller7
        DEPENDS:        dict-server>=1.9.14:../../textproc/dict-server
        BUILD_DEPENDS:  checkperms>=1.1:../../sysutils/checkperms
                        coreutils-[0-9]*:../../sysutils/coreutils
                        dict-server>=1.10.2:../../textproc/dict-server
                        p5-Unicode-Map8-[0-9]*:../../converters/p5-Unicode-Map8
                        perl>=5.0:../../lang/perl5

   textproc/dict-mueller7 is the English-Russian dictionary database
   formatted for dictd (dictionary protocol server). Here perl,
   p5-Unicode-Map8 module and coreutils are build-hosts dependencies as
   they are used for formatting the databases. The same for dict-server
   package as it contains dictfmt(1) and dictzip(1) utilities
   used for formatting and compressing the database. At the same
   time dict-server is also a run-time (target-platform) dependency
   because it provides dictd(8) daemon.

   That is, in order to build dict-mueller7 package you have to do the
   following:
      - build and install on your system all build-host dependencies,
        i.e. perl, p5-Unicode-Map8, dict-server and coreutils
        (with all of their dependencies).
      - build and install all dependencies of the dict-server package for
        target-platform.
      - Surprise! You also have to install perl, p5-Unicode-Map8,
        dict-server and coreutils packages for target platform because
        pkgsrc needs them. Otherwise, the "depends" target complains about
        missing dependencies and tries to install them.
        The problem here is that all these packages are not really
        needed for dict-mueller7 and pkgsrc doesn't provide a way to say
        about it. make(1) does, though
            env ... make package BUILD_DEPENDS=''

        This kind of unnecessary dependencies, especially target-platform
        dependencies, lead to dramatical increase of probability of the
        package build failure. In case of dict-mueller7, the package
        will fail because perl(pkgsrc package) is not crossbuild-friendly.

3) Finally you can run
         env \
           USE_CROSS_COMPILE=yes \
           TOOLDIR=/tooldir \
           CROSS_DESTDIR=/cross_destdir \
           TARGET_ARCH=<arch> \
           CPPFLAGS=--sysroot=/cross_destdir \
           LDFLAGS=--sysroot=/cross_destdir \
           make package

   and build dict-mueller7 for your arm/mips/sh4/whatever.

DistBB now automates steps 2) and 3). It builds, if necessary, and
installs *both* target-platform and build-platform dependencies as soon
as they are needed in the correct order.

---------------------------------------------------------------------------------
Now, let's forget about distbb. A few comments on the separation between
build-host and target-host dependencies.

///
        PKGNAME:        dict-mueller7-1.2
        PKGPATH:        textproc/dict-mueller7
th      BUILD_DEPENDS:  checkperms>=1.1:../../sysutils/checkperms
th                      coreutils-[0-9]*:../../sysutils/coreutils
th                      dict-server>=1.10.2:../../textproc/dict-server
th                      p5-Unicode-Map8-[0-9]*:../../converters/p5-Unicode-Map8
th                      perl>=5.0:../../lang/perl5

///
        PKGNAME:        xdm-1.1.11
        PKGPATH:        x11/xdm
th      BUILD_DEPENDS:  checkperms>=1.1:../../sysutils/checkperms
BH                      inputproto>=1.4:../../x11/inputproto
BH                      kbproto>=1.0.2:../../x11/kbproto
th                      libtool-base>=2.2.6bnb3:../../devel/libtool-base
th                      pkg-config>=0.19:../../devel/pkg-config
BH                      renderproto>=0.9.3nb1:../../x11/renderproto
BH                      renderproto>=0.9:../../x11/renderproto
BH                      xcb-proto>=1.4:../../x11/xcb-proto
BH                      xextproto>=7.0:../../x11/xextproto
BH                      xineramaproto>=1.1.1:../../x11/xineramaproto
BH                      xproto>=7.0.9:../../x11/xproto

"th" means target-host dependency, "BH" -- build host dependency.
I know the difference, pkgsrc doesn't.

I'm able to create a hack on top of make(1) and BUILDLINK_DEPMETHOD.xxxx
variables in order to avoid this problem but I don't think this is the
right way to go.

-- 
Best regards, Aleksey Cheusov.