tech-pkg archive

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

Re: pkgsrc cross-compilation

(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 <>

   - 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).

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

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
and BUILD_LINK_DEPENDS, or something.  TOOL_DEPENDS should be built
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.


Home | Main Index | Thread Index | Old Index