[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkgsrc cross-compilation
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
My proposal for incremental change is to declare that semantics for
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 
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
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.
Main Index |
Thread Index |