[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: both native & bytecode



Hi,

* 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 heavy
status file parsing, and it seem to know over 20k packages on my install (sid
+ 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 gets
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 proud
of.

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).

Cheers,

Samuel.



Reply to: