On Aug 19, 2007, at 3:28 AM, Andy Green wrote:
Hi Jeff -
OK. So you want a "build system" tool able to build package(s) for
multiple target platforms.
You need to look at the fundamental design issue first:
Multiple target platforms (in general) is more than i[3456]86
targets,
and that means remote execution (or emulation).
Yes there is cross-compilation too. There are only a handful of
attempts to
produce *.rpm distros with cross--compilation. The attempts were
successful,
but the package sets were limited to those packages that could be built
(or easily patched) into cross-compiles.
That hasn't been my experience, all it means is selecting the right
cross toolchain using %{_target_cpu}. I don't have to do remote
execution or emulation at all... modern autoblah has removed the
need to
run things to find out int size and so on. You can usually regenerate
./configure using more modern autoblah on packages that started off
the
bad old way of wanting to run test apps in configure.
Not all packages use modern autoblah is the impediment to cross-compiles
Even unpleasant situations found in perl and python where they build a
compiler during the build that is used for the rest of the build
can be
solved with trickery in .spec of building entirely for host,
caching the
resulting compiler, then building again for the target and taking care
to use the host-built compiler at the right moment. (Well, I didn't
need perl or python that bad, but this is my plan to get around it
if I
ever did).
Very specifically _NOT_ attempted are the mechanics of entering/
leaving
a chroot,
installing missing build elements, remote scriptlet execution,
logging
output, etc.
None of that is needed for a cross-compile rpmbuild.
Yep. But the major impediment I hear of is that /bin/sh is not native in
a chroot, and so rpmbuild (and rpm install) scriptlets will not run.
Well, duh ...
Far more reliable is the simple shell loop
for t in target1 target2 target3; do rpmbuild -ba --target $t
foo.spec; done
Yep that is what worked for me.
OTOH, I do believe that generating a *.src.rpm immediately after
parsing,
not after building (as currently), starts to address the fundamental
issue of
multiple srpm's, with possibly differing content, being generated on
multiple
target(s).
The fundamental design decision will be whether there is one single
canonical
master src.rpm, or whether srpm's indeed should be considered per-
platform
with potentially different content.
IMO one single srpm that can be captured and then given to fulfill
(source provision, anyway) license requirements for any GPL or LGPL
binary for any target you have distributed is the only sane way.
I don't disagree. However, there are those who insist on writing %ifarch
peculier spec files that will produce differing content, and blame
*.src.rpm
for not being sufficiently like tar.
Another fundamental question here is about whether crosscompile is the
official way to build for other targets rather than entering to
half-working morass of "remote scriplet execution" and other
stickyness.
I really recommend cross compile and it's reasonably well supported
already, although the dependency stuff is inadequate to deal with the
situation that you have an RPM database that talks about the build
host
environment AND an RPM database that talks about the cross build
environment for the current target.
There are many reasons to attempt remote execution of build
scriptlets, not
just to have %{_target_cpu} on remote != local.
There is nothing whatsoever stopping you from using --dbpath (or
change %_dbpath)
to have rpmbuild use multiple rpmdb's. Throwing massive amounts of
cross-packaged garbage into
a single rpmdb and expecting rpm to sort out the mess is naive. I
certainly cannot justify
my time expenditure to support the vanishingly small needs of cross
compilation build hosts.
Meanwhile I'd certainly like to see more cros-compilation used. What
I actually see is
that few have the time/energy to maintain cross-tool chains, and who
have the methodolgy
and discipline to setup cross build machines, all using *.rpm packages.
Note "all using *.rpm packages" qualifier.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
