Aleksey Cheusov <cheusov%tut.by@localhost> writes: >> First, I am using > >> host: the host on which we are doing cross >> target: the host we are building to > >> but maybe we should be using autoconf terminology > >> build: the system we are building on >> host: the system we are building for >> target: the system the compiler we are canadian cross building >> compiles to > > I'm familiar with autotools terminology and avoided using it explicitely > because I think the word "host" says nothing. This is why used > "build platform" (platform of the system where we build the software > using cross-tools) and > "target platform" (platform we build the software for). > If you think host/target is better I'm fine with it. No problem. I don't think it's better; I was just pointing out confusion. Perhaps doc/HOWTO-crosscompile can just define "build" and "target" explicitly and then we can just use them. The Canadian Cross situation is odd, and I don't think we really need to deal with it. >> BUILD_DEPENDS should be about target, and is really a weak case of bl3 > I think in most cases BUILD_DEPENDS are build host dependencies too. > I could not find cases where BUILD_DEPENDS is set manually in package's > Makefile and contains target-platform dependency. This is where I am not following. In the example you posted, there are a lot of packages listed as BUILD_DEPENDS which provide header files. Those are in my mind target dependencies and the packages should be installed in the target chroot to provide the .h files. It's basically always wrong to include a build .h file in a cross compile. > bl3 is a pure target-platform only dependency. agreed. > If we stay with BUILD_DEPENDS as a list of host dependencies > and introduce TARGET_BUILD_DEPENDS > for bl3 (BUILDLINK_DEPMETHOD.xxx = build), > it will be easier to manually convert BUILD_DEPENDS to > TARGET_BUILD_DEPENDS in packages's Makefile when necessary. > >> HOST_BUILD_DEPENDS is a special case of things that should be USE_TOOLS. > They cannot. Otherwise our USE_TOOLS will have to support thousands of > programs. > >> On rereading I don't follow your BH/th labels; they seem exactly >> backwards. > BH -- build-host dependency > th -- target-host dependency. What I meant is in your list: 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 I think checkperms, libtool-base, and pkg-config need to be present on the build system, since they have to run during package creation, and thus should be "BH". They are probably all better off as USE_TOOLS. The rest, *proto, are .h files that should be present in the target destdir, and should be "th". I realize that if build is NetBSD/i386 and target is NetBSD/arm, then the .h files are the same. But really those .h files are part of the target environment (consider compiling for NetBSD/arm on Solaris, or cygwin). It's important for consistent results that the build machine's include files not be visible to the cross compiler. The other question is: why isn't the *proto dependencies expressed via bl3? I guess what I'm thinking is that BUILD_DEPENDS in a package makefile is basically a bug, to be fixed by either bl3 (for target depends) or USE_TOOLS (for host depends). grepping in devel/*/Makefile, I find 244 BUILD_DEPENDS, or about 1 in 6.8 packages. A quick scan makes me think some are simply candidates for USE_TOOLS, and some are dependencies for running tests. In that case they are really target dependencies that then lead to tests that can't be run. So maybe we need TEST_DEPENDS that are disabled for cross, but are target dependencies for native (or perhaps only if 'make test') is invoked.
Attachment:
pgpjrpZ1KX4Vk.pgp
Description: PGP signature