Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Alternative proposal: COAN
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven Luther <luther@d...>
Subject: Re: [Caml-list] Alternative proposal: COAN
On Wed, Feb 26, 2003 at 11:35:09AM +0100, Olivier Andrieu wrote:
>  Sven Luther [Wednesday 26 February 2003] :
>  >
>  > On Wed, Feb 26, 2003 at 10:47:47AM +0100, Michal Moskal wrote:
>  > > On Tue, Feb 25, 2003 at 11:59:18PM +0100, Sven Luther wrote:
>  > > > > Look how much perl modules is debianized and how much ocaml
>  > > > > modules is.
>  > > > 
>  > > > This is because there are much more debian maintainers who package perl
>  > > > stuff, than debian maintainers who package ocaml stuff. Also mostly we
>  > > > prefer to package stuff we use, as it is much easier to do high quality
>  > > > packages in these cases. And help is always welcome. I guess it is the
>  > > > same for PLD too.
>  > > 
>  > > But the perl packages are *much* easier to package. And that's because
>  > > they're standardized.
>  > 
>  > Well, i guess well written ocaml packages are quite easy to package
> 
> The problem is that every package has a different build system,
> configuration system (Makefile targets), installation directories,
> etc. Of course it is "easy" to package them : just issue the right
> (Makefile or whatever) commands, set the right Makefile variables,

Sure, you just need to correctly read the README or INSTALL file, where
it usually is written, together with the build depends.

> etc. The problem is that you have to spend some time figuring out
> these commands. Ideally, it should be as simple as :
> 
>   perl Makefile.Pl
> or
>   python ./setup.py build

Well, the debian way is to have the maintainers do a (little) bit more
work, and have everyone else just rely on apt-get. Also, we separate the
configuration, building and installation phases. Also, some parts need a
bit more complicated things, like separating arch-dependent from
arch-independent parts, eventually installing stuff in policy mandated
places and other such.

I think it is not really all that much work, once the
bytecode/nativecode makefile targets are well written and that DESTDIR
is supported.

> One more point is that ocaml is multi-platform : so this build system
> should be able to run on unix, Windows, MacOS. Packages that wraps C
> libraries will probably be platform-specific but it think it would be
> nice if pure ocaml programs could be built the same way on every
> platform supported by ocaml.

Again speaks the non-package user. I personally don't care all that
much, as you may guess, and i believe that i could manage to build
packages of ocaml stuff for win32 and macos directly from the debian
packages. What more do you need ? I think there was even a
debian/solaris port some time ago, but i don't know what did become of
it. Anyway, i am running linux on my sparc box.

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