Re: both native & bytecode
On Wed, Oct 27, 2004 at 10:25:29PM +0200, Samuel Mimram wrote:
> >>* You should not build-depend on ocaml-native-compilers since it is not
> >>available on some non-native archs. You could depend on
> >>ocaml-best-compilers but anyway your app is, I guess, small enough not
> >>to require native compilers when available.
> >I thought so at first, but had second thought about it. Ara does pretty
> >status file parsing, and it seem to know over 20k packages on my install
> >+ some stuff), so altough this is disk bound, a native code version is well
> >waranted (unless i am missing something).
> Hum I did not mean that... Of course natively compiled programs are faster!
> My point was only about the dependency on ocaml-native-compilers which
> provides ocamlc.opt, ocamlopt.opt, etc and is only really necessary for
> programs with quite a big source code (it just speeds up the compilation
> time). And anyway, if you want to use that, the source package should
> build-dep on ocaml-best-compilers and not on ocaml-native-compilers I
> think because ocaml-native-compilers is not present on non-native archs
> (that's why best-compilers was made I guess).
> >>* I don't really see the point in providing both ara and ara-byte (and
> >>idem for xara-gtk). You could simply provide an ara package which
> >>contains native ara on archs which support that and bytecode else.
> >No, please don't. The nice thing with this is that the bytecode version
> >built only one time, so you save 3 times the space, and don't need to
> >build on
> >mipsel, mips, m68k and s390. For this alone, it is worth it. I do this for
> >spamoracle, and it works fairly well, and is a setup i am particularly
> Mmm good point. I had not thought of that. I think we should come to
> some kind of consensus on that and put it in the ocaml-packaging-policy
> (in particular I could do that for the coq package which is quite big
> and takes a long time to build).
Notice that it will only work if there are no C bindings in the package, since
those will need to be built in both cases anyway. Ideally those should be
split of as libraries though. This is why i don't do that in the advi package
which would also be a good candidate for such behavior.
There was some discusiion about this some year or so back on this list, and i
would suggest making it the default all right.
There are actually three cases :
spamoracle -> pure ocaml -> bytecode and native code.
advi -> has C bindings, rebuild the bytecode on each arch.
ledit -> to small for native code to be worth it -> bytecode only.