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

Re: splitting ocaml-native-compilers

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
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
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"

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

My 0.02 EUR


Stefano "Zack" Zacchiroli <zack@cs.unibo.it> ICQ# 33538863
Home Page: http://www.cs.unibo.it/~zacchiro
Undergraduate student of Computer Science @ University of Bologna, Italy
                 - Information wants to be Open -

Attachment: pgp0P0Z0y3e2D.pgp
Description: PGP signature

Reply to: