Date: Tue, 1 Jan 2013 03:31:53 +1100 From: "Michael Vale" <masked@internode.on.net> To: "Garrett Cooper" <yanegomi@gmail.com> Cc: freebsd-hackers@freebsd.org, "Simon J. Gerraty" <sjg@juniper.net>, freebsd-ports@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross Compiling of ports Makefiles. Message-ID: <62E9D311E3F4410C93F39BF78047F4C4@forexamplePC> In-Reply-To: <CAGH67wT8=Nwhy=40k=x18Qk2KaWL-pJ7QQhs94kz=hLXBUupJA@mail.gmail.com> References: <E49F944634B24A7387BC937CBE19D2D9@forexamplePC> <20121227180044.7947F58094@chaos.jnpr.net> <641F54E990B14A0AB0A287AE7F810192@forexamplePC> <CAGH67wT8=Nwhy=40k=x18Qk2KaWL-pJ7QQhs94kz=hLXBUupJA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message-----
From: Garrett Cooper
Sent: Tuesday, January 01, 2013 2:37 AM
To: Michael Vale
Cc: freebsd-hackers@freebsd.org ; freebsd-arch@freebsd.org ;
freebsd-ports@freebsd.org ; Simon J. Gerraty
Subject: Re: Cross Compiling of ports Makefiles.
On Mon, Dec 31, 2012 at 6:33 AM, Michael Vale <masked@internode.on.net>
wrote:
> -----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’s 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=/usr/local
make all
make install DESTDIR=/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.
Ahh, What I think I meant was their DESTDIR is skewed because it installs
into ${JAILDIR}, not ${DESTDIR}${ROOTFS}, which could just == ${DESTDIR}.
${PREFIX} cannot be used as it is required to be correct for pkg register,
pkgdb, ldconfig etc.
> 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’s DESTDIR ${makeobjDESTDIR} before running do-install. Now i’ve
>> 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=/usr/obj/crossoutroot/
> DESTDIR=${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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/5998 - Release Date: 12/30/12
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2637/5998 - Release Date: 12/30/12
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62E9D311E3F4410C93F39BF78047F4C4>