Re: [Caml-list] The DLL-hell of O'Caml

[Sven <luther@dpt-info.u-strasbg.fr>]

On Thu, Mar 21, 2002 at 07:10:28PM +0100, Xavier Leroy wrote:
> > Ugh.  I wholeheartedly disagree with source-only
> > distribution.  Such a choice condemns ocaml and all of its
> > applications to remain merely "hacker tools".  And all the
> > worse to mandate a "all downstream dependencies recompile"
> > policy.  I for one need to be able to someday hope that
> > "regular users" will use my program.  Every ignorant user
> > should _not_ be subjected to building and rebuild his own
> > large system because of some deep semantics issue which
> > researchers haven't quite cracked.
> 
> You're confusing whole programs with libraries.  A program can be
> distributed as a statically-linked executable (ocamlopt -ccopt -static
> or ocamlc -custom -ccopt -static), which will run happily on many,

Unless they are not running i386 that is, ...

> 
> This is not what I'm proposing.  It is perfectly feasible to make a
> binary OCaml "distribution" (in the sense of Debian and RedHat being
> "distributions") such as the CDK.  Someone (the distributor) just did
> all the work of building a large collection of sources for you.
> 
> Indeed, a truly automated build procedure like I propose would make
> the work of the CDK maintainers much easier.
> 
> What I think is futile is to expect users to pick independently-
> compiled binary distributions of libraries and dynamically-linked executables
> left and right, and expect that the resulting system will work.  Try
> to do this with a Linux system and it will break very quickly.
> 
> > (I don't think anybody has been so deluded to suggest this in a
> > large system.)  Now suppose you write device drivers.
> > Device driver programmers were frustrated enough before the
> > linux kernel was modularized so that they could load and
> > unload them without relinking the kernel and rebooting.  You
> > mean to tell them now that they must recompile not only the
> > kernel, but therefore the entire machine every time they
> > make a one line bugfix?  What kind of use would a machine
> > like that be?
> 
> More rethorical questions that don't make much sense to me.
> Loading/unloading kernel modules during kernel development is at best
> a dynamic loading issue.  That they might have to recompile their
> driver when the kernel changes doesn't bother kernel developers in the
> least.
> 
> > As a historical reference, the Debian project, having the
> > hacker mentality they do, apparently also fanatasized about
>                                             ^^^^^^^^^^^

This must have been a long time ago, today there is no quation on going away
with biunary package, altough there still exist some exception (like pine i
think, where only source distribution is authorized).

But then again, we distribute various rather slow arches (m68k and arm), and
there may be user on slow i386 systems out there also, i don't think they
would like to rebuild everything everytime something changed.

Binary distribution are the key of the success of GNU/Linux, without it, it
never would have attained the widespread use it has today.

> Again, I don't have anything against binary distributions, as long as
> there's an underlying source distribution and recompilation manager
> that lets me bring things up to date if a binary incompatibility
> arises.  RPMs get close to this but lack a "rebuild and install what
> needs to be recompiled" command.  Maybe Debian's packages or BSD ports
> are better in this respect.

on debian you can just do :

apt-get source -b ocaml

and it will fetch the ocaml source package and build it, you still need to
install it yourself.

There are build dependencies in package, it is possible to check for them, to
have them automatically installed when building a package, and other such
stuff, but i am not very familiar with them, it being a long time since i did
porting work (mostly m68k and powerpc).

We also have autobuilders, which build stuff for all the majors arches.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners