Date: Wed, 30 Nov 2011 20:06:31 -0800 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: freebsd-embedded@freebsd.org Subject: Ports cross-compilation Message-ID: <4ED6FD47.6050704@bluezbox.com>
next in thread | raw e-mail | index | archive | help
I've been tinkering with ports cross-compilation for a couple of days
and decided to summarize this experience. It might start some
discussion, or, with any luck, some action.
I had embedded platforms on my mind and for this use-case we do not
need all the ports to be cross-compilable. What we need is set of tools
to make cross-compilation possible and with these tols porters can start
adopting existing ports and explicitly marking them as cross-compilable.
With this objective I started to add hacks to ports/Mk and tried to
create several generic applications. Here is what I have discovered
so far:
- xdev-generated compilers can be used as toolchains for ports
cross-compilation. Some adaptation are required due to different
platform naming in GNU configure (e.g. mips64eb vs mips64)
- Ports lack "buildroot" notion. There is no distinction between TARGET
directory and PREFIX. Target directory is always assumed to be root
directory. DESTDIR knob tries to fix this but it's more of a shortcut
than proper solution - it just places installation process in chrooted
environment leaving it agnostic of real target directory
- Dependencies should be split in two groups: host dependencies (build
tools) and target dependencies (libraries)
- Package builder works only on installed port. It allows some ports to
make no distinction between two steps: (a) generate files tree for
packaging and (b) generate files during installation. e.g.
pre-compiling function files for shells/zsh: port tries to do it as
a part of post-install target instead of placing this functionality
in pkg-install script
- Some ports rely on autoconf's ac_try_run test to get some information
about target platform. It fails for cross compilation of course.
Few fail graciously by asking developer to provide this information
as #define, some just stick with default value, some bluntly crash.
This should be dealt with at per-port basis.
- Different sets of patches are required for cross-compilation and
native build (use PATCHFILES?)
- More often than not it's easier to have one more Makefile for
cross-platform port instead of adding .if/.endif to existing one
- bsd.port.mk is too monolithic to squeeze cross-platform stuff into it.
Now, I have somewhat limited experience with cross-platform packaging:
only as a user, not as a creator. So I might have overlooked some
pitfalls. But as I see the plan of action, it's something like this
** actual names for files, variables, targets are irrelevant ATM **
- Add BUILDROOT variable and make all installation targets use it.
May be not all but affected by cross-compilation.
- Create bare-bone version of bsd.port.mk called bsd.xdev.mk. It
should contain target called "xpackage" that would manage
dependencies, install port to ${BUILDROOT}, generate package-related
files and create a package. No package registration. We have a lot of
stuff in bsd.port.mk that could be reused -
fetch/checksum/dependencies. Writing them from scratch makes no sence.
- Makefile for cross-compilable port should be split into three parts:
common, native, cross. It's not clear who should maintain cross part
though.
Hope it makes any sense
P.S. I apologize for the abuse of "cross-" prefix. There is way too
much of it in this email. I'll work on my writing skill.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ED6FD47.6050704>