Discuss: Base packages for Win32 / Win64 / OS X cross-compilation
Richard W.M. Jones
rjones at redhat.com
Thu Feb 12 13:48:50 UTC 2009
On Thu, Feb 12, 2009 at 01:58:38PM +0100, Farkas Levente wrote:
> i think about it a lot last night:-(.
> let's just see the above example. how can we do this?
> cross-zlib.spec can contain 3 subpackage as zlib-win32, zlib-win64 and
> zlib-darwin, but how can we build it? one %build section probably not
> enough since we need make clean; make; 3 times so the first 2 result
> lost in %install section.
Autoconf based packages allow this to be done easily, by creating
subdirectories for each build:
Even if a package doesn't use autoconf, RPM can be instructed to
unpack the tarball as many times as we want into separate directories.
(And even if RPM somehow couldn't do it, we could copy the source tree
So there is no barrier to building multiple versions from a single
> solution can be command line defines to
> rpmbuild like rpmforge do it, but i don't know how can be done it in koji?
> on the other hand create 3x3 spec file for each packages
> (f10,devel,epel-5 and later it'll also add f11 and epel-6) x (mingw32,
> mingw64, darwin) 9-15 packages which are almost the same. so under all
> circumstances i _strongly_ prefer 1 spec file for one package eg.
You're never going to get a single spec file across branches. It is
undesirable anyway because the whole point of the different branches
of Fedora / EPEL is that they represent different levels of maturity
and stability of the software.
However we _can_ have one source RPM in each branch building multiple
binaries. We don't need to modify RPM to do it.
> or we can use our own build server which check out the main spec file
> generate platform specific spec files if there is changes then checkin
> to fedora cvs, tag it and build them in koji. but this need a separate
> build system (may be only a few lines of scripts and can be added to
> fedora infrastructure).
Using our own build server is very undesirable. We gain a lot by
using the Fedora infrastructure, such as building on obscure
architectures (ppc64), mirroring, a dedicated team of admins, etc etc.
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
More information about the mingw