Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost> writes:
> (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.
Yes, I think that's the essence of what Aleksey is trying to do. My
issues in the dicussion were not about this essence. IIRC, I was trying
to get us to use the same language that other cross systems use.
I also believe (bit of a strawman) that any "build-time tool
dependencies" as you call them should be expressed via USE_TOOLS, and
it's a bug (now) to have them in BUILD_DEPENDS.
> 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).
Agreed.
> 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.
I agree. I like the name TOOL_DEPENDS. I tend to want to make
BUILD_DEPENDS mean "bits of this *compiled for the target* are used in
the build, but there is no need to have the packaged exist on the
target".
> 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.
Yes.
> 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),
Agreed, and I don't think it's that hard, and I think it's the easiest
way given that we need to build cross tools. All the hard work will be
in building cross versions of the BUILD_DEPENDS packages, and that's
per-package more than infrastructure.
> 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.
Maybe but we've hoisted a lot into USE_TOOLS, so I think a lot of
BUILD_DEPENDS are either both, or link-time cross usages.
> 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.)
Hmm. That involves building things that aren't needed (sometimes). But
I don't see that separating them is hard, if they would work together.
We just have two variables and use the right one in each place. All the
rest of the work does not change.
> 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.
Yes, I think that's right. Using perl as USE_TOOLS but not
TARGET_BUILD_DEPENDS is doable without getting perl to cross-build.
Attachment:
pgp2iSi2fdMQQ.pgp
Description: PGP signature