Re: splitting ocaml-native-compilers
On Thu, Jan 17, 2002 at 09:34:11AM +0100, Judicaël Courant wrote:
> Hi,
>
> le mer 16-01-2002 à 18:16, Sven a écrit :
> > Hello, ...
> >
> > I have just finished building ocaml 3.04-5, which splits away
> ocamlc.opt,
> > ocamlopt.opt and ocamllex.opt into a package called
> ocaml-native-compilers
> > (not a great name, i think).
> >
> > Does someone have any kind of objection or remark to this ? Or maybe a
> better
> > name ?
> >
>
> I have an objection: if I understand well what you did, this mean that
> ocamlopt.opt for instance will not be provided with the "ocaml" package.
> The package I maintain has a "Build-Depends: ocaml". Its configure
> script checks whether ocamlopt.opt is available and if so, use it
> instead of ocamlopt (if ocamlopt is not available, it uses ocamlc). If
> ocamlopt.opt is no longer included in ocaml, this means that it will
> never be build with ocamlopt.opt (at least with buildd) as I cannot put
> a dependency on ocaml-native-compilers if I want the control file of my
> package to be architecture-independent (I like the portability of ocaml,
> I would not like to deal with architecture-dependent problems). Is not
> this a pity?
Mmm, i suppose you are speaking abou8t coq, isn't it ?
The correct way to handle this is arch depending build deps.
Currently, ocaml.opt (or whatever its name is) is built on arm, alpha, i386,
powerpc and sparc. (ia64 has a bug, but should be added to it).
I don't know exactly how it works, but my understanding is that it is possible
to have coq depend on ocaml.opt on some arches and on ocaml on all the others
(well maybe on ocaml.opt and ocaml in the supported arches case).
> Maybe a fix would be to provide a "fake" ocaml-native-compilers for
> architecture that do not support ocaml-native-compilers?
Mmm, i would prefer not, but then we have to look into this a bit more and see
what is the best solution.
Friendly,
Sven Luther
Reply to: