From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 1 04:06:34 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD2D106567A for ; Thu, 1 Dec 2011 04:06:34 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id A5A9C8FC22 for ; Thu, 1 Dec 2011 04:06:34 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1RVxup-000NIJ-VO for freebsd-embedded@freebsd.org; Wed, 30 Nov 2011 20:06:33 -0800 Message-ID: <4ED6FD47.6050704@bluezbox.com> Date: Wed, 30 Nov 2011 20:06:31 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: 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. [...] Content analysis details: (-4.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list Subject: Ports cross-compilation X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 04:06:34 -0000 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.