Re: splitting ocaml-native-compilers
On Fri, Jan 18, 2002 at 11:25:57AM +0100, Judicaël Courant wrote:
> le ven 18-01-2002 à 10:55, Sven a écrit :
> > I would have to test the existance of the opt.opt files after the compile, to
> > move the files only if they exist, or the build process will bomb on me.
> >
>
> You do not need to test whether they exist: try to move them and ignore
> the error if there is any. Now, if you really want to test the existence
> of some executable files, "test -x" is not so difficult to use.
I would probably make it an arch dependant test, because if the .opt compilers
don't get build if the yshould, then it is an error, and i like to be aware of
those.
> > But then, the empty pseudo package to simplify a build dependency issue don't
> > strike me as aesthetically elegant, and i have some doubts abotu it being the
> > right way of doing this.
> >
> Difficult to agree on what The Right Thing is, but as for elegance, the
> introduction of 0 in arithmetics solved many problems very elegantly;
> mathematicians would not work without the emptyset, and shell
> programmers find /bin/true and /bin/false very convenient; I would not
> program in OCaml without the empty list. All these are very elegant
> concepts. I do not understand why an empty package would not be elegant?
Well, contrary to the marthematical 0, and empty package is not really empty,
and it bloats the archive for nothing.
That said, ocaml providing a virtual package may solve this.
But then, even there, it may not be that good, since it would convey the idea
that the .opt compilers are there.
Maybe the best solution would be for ocaml to provide and
ocaml-no-opt-packages or something such, and have the new packages depend on
ocaml-native-compilers | ocaml-no-opt-packages or something such.
I _may_ agree on that, if it is feasible for me, would it convince you also ?
That said, we would have to rethink the package name, since all current
solutions, except ocaml.opt, convey the idea that this package includes the
ocamlopt compiler, and not only the .opt versions.
> > When a new native code compiler gets available, most probably it will be for a
> > new release of ocaml, and the library at least will need to be rebuilt.
>
> Yes, but I guess the buildd will check that there is a Build-depends and
> rebuilt automatically?
Only if there is a new version or if the porters do it themselves.
> > Maybe
> > even the apps, if things happen like the 3.04 case, and anyway, it is always
> > best to rebuild with the current version of ocaml, especially if your program
> > use dynamic linking of .cmo files and such.
>
> I think you missed the point: there is no single "current version of
> ocaml". There is the version of unstable, the one of testing, and the
No, there is only one version of ocaml (well 2 maybe) the one in stable, we
cannot do anything about it, and it is obsolet anyway (2.07 i think), and the
one in unstable, which is the one that should go into woody, and will go into
testing at the same time your new coq packages will.
I understand that you want your package to be able to be built for any odd
kind of installation a user may have, but that is not our problem, and
especially not mine.
> one of stable. I want my package to compile on as much as versions as
> possible (as for the current version of Coq, it cannot compile on stable
> but it can compile on testing; in fact, I did not even needed to check
> my package compiled on unstable: I know it will compile as it is ok on
> testing and the upstream Coq has been ported to ocaml-3.04).
Mmm, i hope you build it with the unstable version of ocaml ?
> > Another idea would be for ocaml to provide ocaml-opt or whatever for the
> > arches where there is no optimized compiler.
> >
>
> This might indeed be a good idea (it requires no more nor less work than
> providing an empty package). Or even better: provide an ocaml-best
> package in ocaml-native-compilers and provide this package when there is
> no optimized compiler.
Mmm, nice, i like that idea ...
I may most probably go for it.
Friendly,
Sven Luther
Reply to: