On Sat, 13 Oct 2012 14:44:21 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Fri, 12 Oct 2012 09:22:29 +0200 Vincent Torri > <vincent.to...@gmail.com> said: > > > On Fri, Oct 12, 2012 at 8:57 AM, David Seikel <onef...@gmail.com> > > wrote: > > > On Fri, 12 Oct 2012 14:45:57 +0900 Carsten Haitzler (The > > > Rasterman) <ras...@rasterman.com> wrote: > > > > > >> On Fri, 12 Oct 2012 13:05:20 +1000 David Seikel > > >> <onef...@gmail.com> said: > > >> > > >> > On Fri, 12 Oct 2012 11:47:25 +0900 Carsten Haitzler (The > > >> > Rasterman) <ras...@rasterman.com> wrote: > > >> > > > >> > > yup. this is going to be a general issue to solve in the > > >> > > build tree. we need to ensure the new efl tree can compile > > >> > > and bootstrap itself on a system wih zero previous efl. this > > >> > > is going to be tricky once we get to running eet, epp, > > >> > > embryo_cc and edje_cc. we need a general solutin to these. > > >> > > > >> > The solution I have seen in a couple of places is to have a two > > >> > stage build. First build the tools you will need to build the > > >> > rest, building them for the host system if cross compiling. > > >> > Then use those tools to build it all, including building the > > >> > tools once more. The tools built during the first pass can be > > >> > cut down versions, only enough to be able to build the rest. > > >> > For instance, edje_cc probably wont need Lua support for the > > >> > first pass. > > >> > > >> yeah. i'm mulling such a thing. 2 stage - build tools, install > > >> in a tmp dir tree in the build tree then use them to continue > > >> the build after that. this hurts cross-compile unless we make > > >> the compile 2 stage like: > > >> > > >> ./configure > > >> make bootstrap > > >> make > > >> make install > > >> > > >> (so the bootstrap can be provides separately in $PATH in the > > >> build host architecture). > > >> > > >> or > > >> > > >> ./configure --disable-bootstrap > > >> make > > >> make install > > >> > > >> for cross-build etc. > > >> > > > > > > That will be why I said that during cross compiling, the first > > > stage builds the tools for the HOST system. B-) > > > > > > I think Vincent is already doing something like this. I remember > > > that he was building Windows releases under Linux? > > > > http://www.gnu.org/software/autoconf/manual/autoconf.html#Hosts-and-Cross_002dCompilation > > yeah - i was mulling if build != host then we do a 2 stage > automatically as part of "make" but then we need to re-configure > using build == host to build the tools. this may be problematic with > cross-build toolchains like OE that already build a set of native > host tools separately anyway and scratchbox like setups that are > hybrid cross-chains that dont need to build native tools to work. so > i'm of the opinion that cross-compiling can stick to > --disable-boostrap and we otherwise always build a subset of efl and > tools, do a tmp install in the build dir, then continue with the > build (and of course set $PATH so our installed tmp tools are found > first). For what it's worth, Aboriginal Linux (which I use for my embedded stuff) cross compiles the basic compiler tool chain, then boots into QEMU to build the rest. It basically cross compiles barely enough OS + C compiler to be self hosting, then builds whatever else you want inside that OS. Since EFL is in the "whatever else" part, I don't need to worry about cross compiling it. The Aboriginal Linux catch cry is "We cross compile, so you don't have to.". So I'm aware of cross compiling issues, just neatly side step them in my own work. I'd forgotten the build/host distinction when I said "host". Aboriginal has what they call an "airlock" step, where they build a native toolchain, including busybox and C library, then use that to build the real cross compiling tool chain. In an effort to keep anything subtle from creeping into the cross compiler from whatever OS you are building on. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
