Re: pkgsrc cross-compilation

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

(I am not subscribed to tech-pkg, so please cc me in replies.)

   Date: Tue, 26 Mar 2013 23:54:54 +0300
   From: Aleksey Cheusov <cheusov%tut.by@localhost>

   - I proposed a solution -- introduction of new variables for separating
     target and build host dependencies. I also provided initial patch
     for this. Here it is (in the end of the message).
     http://mail-index.netbsd.org/tech-pkg/2011/11/19/msg008003.html

It looks like your patch tries to automatically distinguish two kinds
of build dependencies and then carefully choose which ones the mk/
machinery actually recursively builds.  The two kinds are

- what we might call `build-time tool dependencies', meaning `we need
  to run this tool on the host at build-time', such as the compiler or
  flex or tic or Perl; and

- what we might call `build-time link dependencies', meaning `we need
  this package to be available at build-time to compile and link
  against it', such as X header files from x11/xproto or libfl.a from
  devel/flex.

We currently identify these two as just BUILD_DEPENDS because they
coincide in the case of native compilation, and are sometimes bundled
together (e.g., devel/flex provides bin/flex and lib/libfl.a).  For
cross-compilation, though, it seems to me that we ought to make the
distinction first-class in the dependency logic -- perhaps replacing
BUILD_DEPENDS by TOOL_DEPENDS and LINK_DEPENDS, or BUILD_TOOL_DEPENDS
and BUILD_LINK_DEPENDS, or something.  TOOL_DEPENDS should be built
for the host with USE_CROSS_COMPILE=no TARGET_ARCH=${MACHINE_ARCH};
LINK_DEPENDS should be built for the target with USE_CROSS_COMPILE and
MACHINE_ARCH preserved.

This would require 

(a) adding some machinery under mk/, and

(b) going through the uses of BUILD_DEPENDS and classifying them
(keeping BUILD_DEPENDS around to imply one or the other, or both),

although I suspect it may turn out -- as your patch seems to guess --
that most direct uses of BUILD_DEPENDS mean build-time tool
dependencies and most uses of buildlink3 with depmethod=build mean
build-time link dependencies, making (b) much easier.


I discussed this with joerg@ yesterday.  He opined that distinguishing
these two cases would complicate mk/ and become a maintenance burden
for packages, and that it would be better to just build both host and
target packages for all build dependencies, whether they be build-time
tool dependencies or build-time link dependencies.  (joerg@, please
correct me if I have misunderstood or misrepresented what you said.)

However, it seems to me that

(a) the main burden on packages would be the initial pass over the
BUILD_DEPENDS, and that can be done incrementally and easily -- things
will fail noisily if you classify them wrong; and

(b) if we build both host and target packages, then before we can make
much progress on packages that we're interested in cross-compiling, we
need all the tools to be cross-compilable too -- including major
cross-compilation headaches like Perl.

Thoughts?