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: %build mkdir build-foo cd build-foo ../configure make cd .. mkdir build-bar cd build-bar ../configure make cd .. 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 ourselves). So there is no barrier to building multiple versions from a single source file. > 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. > cross-zlib.spec. 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. Rich. -- 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. http://et.redhat.com/~rjones/virt-p2v _______________________________________________ fedora-mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
