tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: distbb for cross-compiling packages

Aleksey Cheusov <> 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.


> If we stay with BUILD_DEPENDS as a list of host dependencies
> and introduce TARGET_BUILD_DEPENDS
> for bl3 ( = 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

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

Home | Main Index | Thread Index | Old Index