Re: pkgsrc cross-compilation

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

   Date: Fri, 29 Mar 2013 08:33:42 -0400
   From: Greg Troxel <gdt%ir.bbn.com@localhost>

   I think this isn't actually as hard as it seems, because generally
   cross-building is non-functional now.  So if we don't break native
   (host==target) package builds, and it gets easier to make a package
   build cross (assuming the upstream package builds cross), then it's
   strictly better.

Agree.

   My proposal for incremental change is to declare that semantics for
   variables are:

     BUILD_DEPENDS: target, needed at build time only
     DEPENDS: target, needed at run time and build time (to link against)
     RUN_DEPENDS: target, needed at run time only [1]

     HOST_BUILD_DEPENDS: host, needed at build time only (to run on host)

   To have no loss, we only need HOST_BUILD_DEPENDS to act like
   BUILD_DEPENDS on native (target == host) builds.  Then, people can try
   to build cross, and put things in HOST_BUILD_DEPENDS (and perhaps remove
   them from BUILD_DEPENDS).

Sounds good.  I worked on a patch to do this last night, except I
provisionally called it TOOL_DEPENDS instead of HOST_BUILD_DEPENDS,
with the intent to change it to something better because we already
have a different meaning for the word `tool'.

My only reservation with the word `host-build' is that it ill matches
the GNU cross-compilation nomenclature, in which `--build' and
`--host' are what we (and, well, just about everyone else) currently
call `host' and `target', respectively.  How about `native-build'
instead, to avoid that name conflict?

The patch I made last night got x11/xterm from modular X.org built
almost completely automatically, including all the xcb tools and stuff
-- the only manual steps were setting up the NetBSD destdir and
tooldir, and setting up the cross-libtool kludge.

[Aside:  I wonder whether there is an important distinction between
bootstrap depends and host-build depends.  As I implemented host-build
it is semantically a bit different, but if -- after careful
consideration, which I haven't done yet -- it turns out that the
difference doesn't matter, it might be nice to reduce the number of
concepts involved.  Something to consider later.]

   Am I missing some complexity?

A little: buildlink3 depmethod.  Some uses of buildlink3 really want
HOST_BUILD_DEPENDS, or possibly in some cases both HOST_BUILD_DEPENDS
and (BUILD_)DEPENDS, but at present, BUILDLINK_DEPMETHOD.mumble can be
only `full' or `build'.  For now I've provisionally added `host-build'
as another valid value, but we'll have to revisit that.

Examples of buildlink3 dependencies that want HOST_BUILD_DEPENDS:

lang/python/pyversion.mk with PYTHON_FOR_BUILD_ONLY
textproc/xmlcatmgr/catalogs.mk

It may be that these should just use HOST_BUILD_DEPENDS directly
instead of, or in addition to, buildlink3, and that buildlink3 makes
sense only for, well, build and link stuff in the target.  I don't yet
understand buildlink3 well enough to say.