Brendan Conoboy wrote:
> Ed Swierk wrote:
>> Isn't that exactly what we'd get with target emulation? Any available
>> host that can run an emulator could then build all of fedora Fedora
>> for ARM or PowerPC or whatever.
>
> I don't mean to exclude target emulation as an option, it's just not
> where my particular interest is. Here's why:
>
> 1. It is always slower than native or cross compilation.
>
> 2. It only exists for a small number of platforms.
2a or 3. It's not self seeding. If you have a cross toolchain (gcc,
binutils), you can generate all the target packages needed for a normal
runlevel 3 or 5 environment on the target with just the cross toolchain
and a set of SRPMs. But for the emulation case, you somehow needed a
runlevel 3 working set of binary packages for the target arch (so you
can boot it and compile) before you can start making target packages.
Progress with new arches will therefore be faster and more distributed
with the cross method assuming there is a flexible way to make arbitrary
cross toolchains (like rpmbuild --rebuild --target=s390
--runtime-generates=arm gcc-4.0.2-1234.src.rpm ) ... unfortunately
rpmbuild target doesn't have the same meaning as in configure.
> One of the advantages of cross compiling is that it's not just for arm,
> it's for anything. You can create a mesh of cross compilers such that
> any arch can build a target for any other arch. Is the s390 slow or
> down? No problem, build on one of the plentiful x86 hosts. Cross
> compilation has the potential to realize maximum use of build hosts and
> consequently turn around faster builds.
Right and not only that to empower everyone to kick out s390 versions of
their packages if they want. They just install s390 cross toolchain and
-devel packages somewhere and rpmbuild --rebuild --target=s390
blah.src.rpm. At the least they can make sure it compiles clean, and
hopefully can find an s390 vict... tester.
>> Supporting cross-compiling would be great, but having spent a several
>> weeks fighting with Python and its libraries last year and losing, I
>> suspect scouring the other nine zillion Fedora packages for
>
> Packages like Python and Perl do take some work, but a number of
> individuals have already done that work. Multiple times. Multiple
> approaches. Fedora becoming cross friendly could have the effect of
> unifying those efforts, getting cross changes upstream, ending all the
> waste.
Yes, and that would improve the situation for a large and increasing
number of embedded folk who may not even use Fedora, that is valuable work.
>> That said, there is certainly room for both approaches, and getting
>> even a small number of packages to cross-compile might be enough for
>> many embedded applications.
>
> Definitely. For cross compilation, I picture a per-package flag in Koji
> that marks it as cross-friendly or not. There are certainly numerous
> technical and social details to work out to making such a system work
> and work equitably. We're just getting started.
Well some areas to think about
- extending rpmbuild a very little to take a switch to define a new
macro %{_runtime_target_cpu} or somesuch, so cross toolchain packages
can be told what the built compilers should emit
- The disparity in platform resources and power will be greater than
ever before. Choices made in ./configure switches that are the standard
Fedora way can easily blow packages and dependencies out of scope for
otherwise capable targets. You can tie choices in configuration to the
arch, but isn't it more interesting to imagine it is its own "bloat
dimension", so weak x86 targets can be built for? How about being able
to specify multiple %build and Requires based on a new macro %_bloat.
%_bloat = 10 is the normal supported Fedora traditional build with
Kerberos everywhere and so on. But the spec file can also define
alternatives along the lines of %if %_bloat < 10 <alternative config
args> %endif or %switch/%case (either requires a little extension to rpm
AFAIK). Only the default bloat level needs to be supported and shipped
by Fedora to the extent it already is, folks can --rebuild to target
lesser platforms fedgentoo style. %_bloat=1 can even give you a busybox
/ uClibc based result if you want to max it out. But to get started all
the packages can just build the standard way without any conditionals.
- How to install foreign arch libs and -devel packages. There is
already a precedent in having i386 libs on x86_64 boxes but this is a
bit different because the arch is REALLY foreign. It will have to know
to do some kind of --root= action if it sees you installing s390 libs
into an i386 box, because you clearly don't want them going into the
real /lib.
- How yum can keep the foreign arch packages up to date too. The bloat
scheme above would need to issue at least non %_bloat = 10 rpms with a
bloat tag on them so the right -devel stuff gets pulled in
-Andy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
