From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 31 15:37:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F32EF881; Mon, 31 Dec 2012 15:37:19 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2218FC0A; Mon, 31 Dec 2012 15:37:18 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id un3so11366041obb.7 for ; Mon, 31 Dec 2012 07:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uBXqLFDZbyxzE9qw79sdCK3jopldso1qmOhvyiDRBzo=; b=wZxq/fglN06yy5V8n+1wENbLTlElZnXnvoIPmltdcgrGtyQp6RTaa1w13EPolvGaBx 3jFR5IDSKztJbbZtzcPc9A20WnDrim/qy8jXJOcQ6X2thCMN6Ru+XPx1zzeyWRiFBllf lpoazWJg8nRhLn3ZwpHukzdZSP6WX9c9cxYSLs8oS/EUkz9qHdUHJYbaxaDwY6eYtluK u13oJF+bb/9k+z9RDx5ERJt8IgziK6ughRoCzU2jJP6/UtETu6J+RYJjT+4zI72RbIbV rZe3Jx5bewctsj0q0nQ74H6TC2Ri7BpvRtZ+GHpHbVicMs9mVNBFWmf0ymip6bokwe4V w+Pg== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr21777668oeb.24.1356968237743; Mon, 31 Dec 2012 07:37:17 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 31 Dec 2012 07:37:17 -0800 (PST) In-Reply-To: <641F54E990B14A0AB0A287AE7F810192@forexamplePC> References: <20121227180044.7947F58094@chaos.jnpr.net> <641F54E990B14A0AB0A287AE7F810192@forexamplePC> Date: Mon, 31 Dec 2012 07:37:17 -0800 Message-ID: Subject: Re: Cross Compiling of ports Makefiles. From: Garrett Cooper To: Michael Vale Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, freebsd-ports@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 15:37:20 -0000 On Mon, Dec 31, 2012 at 6:33 AM, Michael Vale wro= te: > -----Original Message----- From: Simon J. Gerraty > Sent: Friday, December 28, 2012 5:00 AM > To: Michael Vale > Cc: freebsd-hackers@freebsd.org ; freebsd-arch@freebsd.org ; > freebsd-ports@freebsd.org > Subject: Re: Cross Compiling of ports Makefiles. > > >> Doing the same thing could also prevent the need for a DESTDIR JAIL >> install at all and just use the real build machine=92s build env, rather >> than a jail. Regardless. We still have to install these targets and >> their DESTDIR is skewed. There is a few options, > > > I think I know what you mean, but not clear on the "their DESTDIR is > skewed" bit. You were probably thinking of PREFIX, not DESTDIR. DESTDIR in ports-land should be an install directory wherein if I do... ./configure --prefix=3D/usr/local make all make install DESTDIR=3D/chroot/ It would install all (well, ok most if it needs to touch more of the base system) of the package files into /chroot/usr/local and pathing would be setup appropriately that way. > I'm not sure what I meant here either. Thank-you for taking the time to > read the entire e-mail! :) > >> One is to have a MAKEOBJDIRPREFIX like option, and redefine every >> target=92s DESTDIR ${makeobjDESTDIR} before running do-install. Now i= =92ve >> yet to complete this stage, but I believe this is the way to do it. > > Would it be sufficient to have an INSTALL_PREFIX and/or INSTALL_DESTDIR > so that DESTDIR can be different during install ? > [I was recently experimenting with something similar...] > > > So how would that work? > > pre-install: > INSTALL_DESTDIR=3D/usr/obj/crossoutroot/ > DESTDIR=3D${INSTALL_DESTDIR} > > do-install: > > ? I will try something like that. > > Thank-you for taking the time to reply Simon, I've thought about this item quite a bit and while I might not have hashed out all of the internal details, I think that it should go something like this: 0. Run standard build/install targets which will go and create necessary binaries into a predefined world dir. Once the installation is complete (installworld / distribution)... 1. Mount the necessary mountpoints. 2. Install the "host-compiled" tools into a predefined set of directories. Example: /chroot/h/bin /chroot/h/sbin /chroot/h/usr/bin /chroot/h/usr/libexec /chroot/h/usr/sbin 3. Do a nullfs overlay of the "host-compiled" tools on top of the target system's equivalent directories in order to provide the needed bits for executing the build. 4. Verify sanity for the install base (just in case the new binaries don't run on the host system due to KPI differences) with a basic check like we use for make in `upgrade_checks`. 5. Mock up the build environment to look like the target system, like what's described . 6. Jump into the world dir. 7. Start building/installing packages. Notes: I'm suggesting steps 2. and 3. because while fixing hardcoding in ports packages is a noble effort, there's just way too much work to be done in order to accomplish the job (we have other problems to contend with around the ports tree) and it's an ongoing battle trying to get everyone to use sane build methodologies (I'm making an assumption based on several projects I've used, but many devs aren't capable build system engineers because it takes a bit of mental skewing, so hardcoding abounds in a number of places). Doing this will allow us to have a working prototype quicker, so in the event that others wish to make the process more streamlined in the future, they could do so. Whether or not this handled in the FreeBSD build system or outside it is an implementation detail, but for the sake of modularity (and to keep KISS principle with the FreeBSD build system, which I would argue is complicated enough) I would say make them separate processes. Besides, we already have canned methods for doing this in NanoBSD, PicoBSD, etc already -- and they really could deserve some consolidation (speaking of which, have you looked at using these in zrouter?). You might want to look at FreeNAS 8.x's build architecture and use that as a starting point for how to do things. imp@ designed the initial system, I (gcooper@) modified it heavily, and jhixson@/jpaetzel@ modified it more after I left iXsystems in order to work with their plugin architecture. I can send you a copy of the system I was starting to architect ("Avatar") if you wish. Overall, I like the direction you're going in and I'm glad someone is picking this up. I greatly appreciate it because it's been on my laundry list of items that need to get done for some time :). HTH, -Garrett