Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes: > 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? I see your point. But having had this rattle around in my head for so long, I have come to the conclusion that if pkgsrc uses "HOST" and "TARGET" as the only two words, that's fine. For those not so steeped, autoconf/gcc uses: build: the machine you are running the cross build on host: the machine you are building the program to run on target: the machine the program you built builds binaries for This is to support the "Canadian Cross", where you can on an i386 machine build a compiler to run on alpha which produces arm binaries. That's pretty cool, but we don't really need it for the normal case of pkgsrc. So I've come around to the position that other than a few people who are steeped in autoconf/gcc, people correctly understand "host" and "target", and correct understanding is the point of naming. > 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. That sounds excellent; the destdir/tooldir can be automated easily. If you're feeling brave, you might try that on a Linux or Mac host.[> > [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.] I think the real difference is that bootstrap is special in that building bootstrap tools cannot assume that pkgsrc is functional. So the difference between bootstrap depends and HOST_BUILD_DEPENDS is exactly the differene between bootstrap and regular packages in the native case. > 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. I would say that buildlink3 that is HOST_BUILD_DEPENDS is a bug. If that's what is wanted, it isn't being linked against, it's a build tool. If we decide that USE_TOOLS += foo means to use foo's bl3 with type host-build, that's ok. But we neeed to support a set, not an exclusive option. > 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. I think bl3 should be only about target. The main point is to create a shadow tree of includes and libraries (and pkg-config) so that information from the host does not leak into the build (e.g., configure finding an optional library that is not a dependency but happens to be installed). The intended isolation is between the host environment (which is the target os/cpu environment) and the target build environment. Once the host is not the same arch or os as target, this matters even more, because in the native case a lot of leakage, even though wrong, doesn't matter. There is another issue, which is that some packages have scripts "foo-config" that when called with --libs return libraries to link against. There, you want to run those on the host, hoping they will produce the same answer as if they had been run on the target. The right answer is to fix their upstreams to use pkg-config and turn the config info into data that can be manipulated without risk by a host tool.
Attachment:
pgpNyUjI8J8lm.pgp
Description: PGP signature