tech-pkg archive

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

Re: pkgsrc cross-compilation



On Thu, Mar 28, 2013 at 02:56:50PM +0000, Taylor R Campbell wrote:
> 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.

There are essentially five types of dependencies, once you start with
cross-compiling: bootstrap (i.e. needed before dependency processing is
done), host-build, target-build, runtime-not-needed-on-host,
runtime-also-needed-on-host. The last could be split it, but I am
mentioning it here as it differs from the existing meaning.

I don't think automatic classification is really going to work.

I do believe that until cross-compiliation support is in a far more
mature state, that introducing this kind of split for all but select
cases is just creating churn. In most cases, a host (build) dependency
also ends up as runtime dependency for the target. While there are a few
things that only need Perl as build time dependency, chances are very,
very high that you are also going to install a package that needs it as
full runtime dependency anyway. As such, I would strongly suggest to
just keep the current approach of requiring both host and target
packages to exist for the dependencies and only deal with the special
cases of host tools that need to be aware of the bootstrap. libtool and
compilers from pkgsrc come to mind for that. Note that this doesn't mean
that Perl is a lost case, just that a binary package for it needs to be
crated natively until someone spends to time to write mknative like
wrappers for it. Alternatively, a package could just be faked...

Joerg


Home | Main Index | Thread Index | Old Index