Re: splitting ocaml-native-compilers
On Thu, Jan 17, 2002 at 07:46:42PM +0100, Stefano Zacchiroli wrote:
> On Thu, Jan 17, 2002 at 04:45:21PM +0100, Judica?l Courant wrote:
> > > Ok,first argument is the lazyness of debian packagers.
> > Right. This is possibly an ennoying fact, but this is a *real* fact (you
> > can also add the ignorance of debian packagers --- there are two many
> > possible things to know all of them). Disregarding facts about human
> > nature in software engeenering leads to failure IMHO.
>
> 1) a debian maintainer is supposed to know how debian packaging system
> works
Well, but the packaging system canges over time, and you may miss some subtle
changes, who are not always well documented. Sure, there is always the source,
but then most people have better use of their free time ...
> 2) from my experience if a debian maintainer does not know a "thing"
> (like arch build dependencies) he usually learn to use it in 10 minutes
This is true for most things.
> 3) a debian ocaml maintainer is supposed to follow this list or to look
> at other ocaml debian package so it will know how arch build
> dependencies are to used "for free"
Yes, and we should write a ocaml related policy or something which clarifies
all these things, so it would make life easier for all.
> > > Anyway, i guess there will, in the forseable future, only be coq with such
> > > problems,
> >
> > Why? From my experience, Coq is a very good bench for discovering what
>
> Because coq is at the moment the only big (in size) project that
> probably (but I haven't checked) benefit from using nativecode
> compilers (read: compilers that are themselves nativecode binaries).
>
> > 2) you miss the point that the list of supported architectures changes
> > over time: I want my Coq package to work with as much ocaml versions as
> > possible. In testing, ocaml is 3.02 for the moment. As I wanted Coq to
> > enter testing as soon as possible, I take care not to make it depend on
>
> This is not a problem. IMO we have not to care to much about compilation
> time on build daemon because this is a problem at the moment only for
Well, i am not that sure about this :
1) Judicael cares about this, since he would loose time by rebuilding arches.
2) Especially the arm folk would not be happy if coq takes suddenly the double
of time.
3) In the same vein, resurecting the m68k port would most assuredly make the
m68k autobuilder happy, ... sadly, altough i have a m68k box, i don't really
have the time for it.
> coq and not so big problem: remember that build daemon benefit in using
> native code compilers but they also have to install an additional
> package (ocaml-native-compilers). OTOH we have to care about users that
> wants to build the coq (for example) package by themselves, but if your
> configure script is smart enough, and probably it is, if it find
> ocamlopt.opt well, if it not he can safely use ocamlopt maybe ouputting
> a warning or asking the user to add a flag if he really want to build
> the package with non .opt compilers.
Friendly,
Sven Luther
Reply to: