On Mon, Sep 09, 2002 at 09:59:02AM +0200, Stefano Zacchiroli wrote: > On Sun, Sep 08, 2002 at 06:45:37PM +0200, Sven LUTHER wrote: > > > Great. I will build a bytecode binary-all and a optimised with > > > arch=i386,alpha,...<archs that have ocamlopt>. > > > > Yes, you could also split the package in two binaries, the first one > > being a bytecode package, and arch: all, the other being a native code > > package and arch: <list of supported arches>. > > Please consider if there is a real need to have both version of the > package? Is mldonkey a cpubound software? If this is not the case and if > the user can have no advantages in using a nativecode version then go > for a bytecode-only arch:all version.
Stefano, you don't understand, do you ? If we split the package, there will be 1 arch: all package with the bytecode executable available for all arch, and 1 arch: any package per arch supporting the native code compiler, with the native code compiler. Sure it makes for 1 more package on the native code compiling arches, but the bytecode package would be shared by all arches not supporting it. Note that currently native code compilers are built on : alpha, arm, i386, ia64, powerpc and sparc (6 arches) And are not available on : hppa, m68k, mips, mipsel and s390 (5 arches). This way we not only save the archive of 4 copies of the identical bytecode packages, but also have the added benefit of being able to have either the bytecode or the native code package installed on arches which support both. And we build the bytecode on a possibly faster box that what would have been used for m68k for example. It is less heavy, not more. Friendly, Sven Luther
