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

Re: both native & bytecode



On Wed, Oct 27, 2004 at 10:25:29PM +0200, Samuel Mimram wrote:
> 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).

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.

Friendly,

Sven Luther



Reply to: