Re: [Caml-list] Alternative proposal: COAN

Re: [Caml-list] Alternative proposal: COAN

[Chet Murthy]

>>>>> "NC" == Nicolas Cannasse <warplayer@free.fr> writes:

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

    NC> Will I need to install wonderful programming langages such as
    NC> perl or python on my Windows box ? Without any flames, why are
    NC> always unix users wants to make things so complicated ? :) I
    NC> will much more prefer something like :

Have you tried OCamlMakefile?  I gotta say -- I do a lot of weird
stuff with Caml (preprocessing with a custom-written #define
processor, amongst other weird stuff), and it's worked more-or-less
like a charm.

Indeed, I'd like to encourage others to use this puppy.  It *works*.

A combination of OCamlMakefile, and "findlib" (Thanks, Gerd!!!!)
really, really, really (did I mention really?) works to eliminate
almost all my building and packaging hassles.

I suspect that some sort of Makefile-generating facility, written in
Caml (of course), combined with OcamlMakefile, and producing findlib
modules, would be *near-ideal*.

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

Re: [Caml-list] Alternative proposal: COAN

[Chet Murthy]

>>>>> "NC" == Nicolas Cannasse <warplayer@free.fr> writes:

    NC> No, I haven't used OCamlMakefile ( is is working with NMAKE ? 
    NC> ) And no, I don't think using findlib would be *near-ideal*
    NC> since it isn't ported on all platforms ( Windows at least,
    NC> what about MacOs ? ).

Ahhh ... Windows.  Oh, yeah, I guess, well, yeah, you're probably out
of luck until somebody decides (like ActiveState did for Perl and
Python - and note until they came along, that you were equally
out-of-luck with Perl/Python) to port all the Caml tools nicely.

Until then, well, hmmmm ... I wonder how easy it would be to use
Cygwin ...

Regardless, I think that solving this problem on UNIXes is already
sufficiently valuable that more-or-less standardizing on OCamlMakefile
and findlib would be a big step forward.

It isn't that I'm trying to be bigoted against Windows.  Just that,
well, there are UNIX tools, and Windows tools.  And you aren't going
to find the Windows tools on natively Unix, any more than you'll find
the UNIX tools natively on Windows.

E.g., note that you don't get Visual C++.Net on Unix anywhere.  And
you don't get full xemacs on Windows, except under Cygwin.

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

Re: [Caml-list] Alternative proposal: COAN

[Chet Murthy]

>>>>> "XL" == Xavier Leroy <xavier.leroy@inria.fr> writes:

    XL> Since day one, the OCaml module system has had "hierarchical"
    XL> namespaces in the form of nested modules.  Without sounding
    XL> too cocky, I'd say that ML doesn't have much to learn from
    XL> Java or Perl in the module department.

    XL> The '-pack' mechanism was introduced in 3.06 to support
    XL> separate compilation of the submodules.  Since it is a recent
    XL> extension, it's not yet stable enough to be used widely, but I
    XL> expect this to change with time.

How *amusing*.

Xavier, while you were doing this, I was hacking together, as a piece
of "research" (but then, I work for an industrial "research" lab, so
you can decide for yourself how much "research" I get to do), a real
module system for Java.

Oh, you say (well, -you- wouldn't say it, and you'd be right not to
;-), doesn't Java *have* a module system?  Nope.  In the same sense
that SML/NJ didn't have a notion of compilation/linkage units, back in
1991, when I first met caml-light, Java doesn't have such a notion,
either.  Heck, Java's "packages" are neither hierarchical, nor do the
enforce enough constraints to provide anything remotely resembling
separate compilation or linking.

The linking of any Java class can cause the linking of any other Java
class.  The compilation of any Java class can cause the compilation of
a large number of other Java classes.  They certainly don't allow the
JIT to do anything remotely resembling static compilation.

For achieving "modularity" of a form which permits separate
compilation, hierarchical namespaces is almost irrelevant.  All its
really good for, is for *naming* classes.

After hacking with Java all these years (the horror, the horror), I've
pretty much concluded that something like findlib, with some
extensions to *name* packages more commodiously, would be almost
perfect.

Once we get our Java version of this modularity done, I'm going to
take a look at what one would have to do to findlib (literally, I
think it comes down to module-naming, and that is *all*) to make it
work for large-scale module-sharing.

I really don't think Caml is far.

And I think you're right, Xavier, that you have nothing to learn from
Java and Perl.  Heck, I based the module system I'm writing for Java,
on the old caml-light "compilation units".

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

[Caml-list] Alternative proposal: COAN

[Benjamin C. Pierce]

Although I share the impulse behind the recent discussions about
improving the standard library, I wonder if it is actually missing the
main point: there are *already* lots of improvements on the standard
library out there -- the Unison project has one; probably there are at
least a dozen better ones out there -- but nobody can find them!  This
leads to an idea for a different way of soaking up people's hacking
energies...  :-)

The single thing that I think would make the biggest difference for the
OCaml community is a central repository for OCaml source code --
something analogous to the CPAN archive for PERL modules.  I'm aware of
all the thorny problems involved in really doing something like this
"right" for OCaml, but frankly I'd rather have something simple and
useful, now, than the right thing, someday.  The CDK was an impressive
attempt to do the right thing, but it was too ambitious and sank under
its own weight.

The minimal functionality that seems needed is something like this:
   - a single repository (on somebody's web server, or maybe SourceForge)
     where stuff lives 
   - an easy way for authors to upload stuff to the repository (and to
     re-upload new versions of their stuff)
   - an easy way for users to browse and download stuff
   - some way (at least informal) to indicate dependencies between one
     thing and another in the repository

Of course, much more functionality could be imagined and wished for
(e.g., a machine-readable representation of dependencies, provisions for
mutiple versions, standard installation procedures, documentation
standards, etc., etc.), but all that can be added later, in light of
experience.  For now, let's let a thousand flowers bloom... and just
encourage them to bloom in the same garden!

    - Benjamin

-----------------------------------------------------------------------------
BENJAMIN C. PIERCE, Professor
Dept. of Computer & Information Science                bcpierce@cis.upenn.edu
University of Pennsylvania                                    +1 215 898-2012
200 South 33rd St.                                       Fax: +1 215 898-0587
Philadelphia, PA 19104, USA                http://www.cis.upenn.edu/~bcpierce
-----------------------------------------------------------------------------
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Chris Hecker]

>The single thing that I think would make the biggest difference for the
>OCaml community is a central repository for OCaml source code --
>something analogous to the CPAN archive for PERL modules.  I'm aware of
>all the thorny problems involved in really doing something like this
>"right" for OCaml, but frankly I'd rather have something simple and
>useful, now, than the right thing, someday.

I think this is true, and was my motivation for "voting" for the SF project 
to be created.  I figured once we got the SF thing going, we could turn it 
into a kinda cheapo version of this.  We mirror a bunch of library code 
from other open source caml projects in the tree, in some pseudo-standard 
layout.  Somebody writes a really simple xml schema describing what's up 
there and the dependencies.  Somebody writes a really simple thing to parse 
that and suck down the latest version (either from cvs or by talking to the 
cvsweb client) from the command line, like apt-get or ActivePerl's ppm, and 
attempt to install it.  It would be lame, but it would work for simple 
stuff.  I think getting something/anything started will be a step in that 
direction.

Chris

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

Re: [Caml-list] Alternative proposal: COAN

[Francois Rouaix]

I think that Benjamin has an excellent point here.
As much as I curse CPAN on a regular basis (e.g. for forcing 5.8.0 on 
me), I wouldn't even touch Perl or Perl based apps if it wasn't for 
CPAN and the easiness that it brings for the installation of apps and 
libraries that have non-trivial requirements.

I'd say that the discussions on licences are a waste of time; I think I 
can predict that with more than 40 OSI approved  licenses around and 
more non-OSI licenses available, there will never be a strong majority 
to agree for a specific license for a hypothetical extended OCaml 
library.

What could be done is exactly what Benjamin suggests. To some extent, 
the hump has a few of these functonalities. I'd push for "standard 
installation procedures" as being part of the minimum.

My $0.02...
--f
François Rouaix

> The minimal functionality that seems needed is something like this:
>    - a single repository (on somebody's web server, or maybe 
> SourceForge)
>      where stuff lives
>    - an easy way for authors to upload stuff to the repository (and to
>      re-upload new versions of their stuff)
>    - an easy way for users to browse and download stuff
>    - some way (at least informal) to indicate dependencies between one
>      thing and another in the repository
>
> Of course, much more functionality could be imagined and wished for
> (e.g., a machine-readable representation of dependencies, provisions 
> for
> mutiple versions, standard installation procedures, documentation
> standards, etc., etc.), but all that can be added later, in light of
> experience.  For now, let's let a thousand flowers bloom... and just
> encourage them to bloom in the same garden!
>
>     - Benjamin
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Basile STARYNKEVITCH]

>>>>> "Francois" == Francois Rouaix <francois@rouaix.org> writes:

    Francois> I think that Benjamin has an excellent point here.  As
    Francois> much as I curse CPAN on a regular basis (e.g. for
    Francois> forcing 5.8.0 on me), I wouldn't even touch Perl or Perl
    Francois> based apps if it wasn't for CPAN and the easiness that
    Francois> it brings for the installation of apps and libraries
    Francois> that have non-trivial requirements.

    Francois> I'd say that the discussions on licences are a waste of
    Francois> time; [...]

Agreed. But some licenses are better than others... (and some core
libraries could have a dual-license if so needed).

    Francois> What could be done is exactly what Benjamin suggests. To
    Francois> some extent, the hump has a few of these
    Francois> functonalities. I'd push for "standard installation
    Francois> procedures" as being part of the minimum. [...]

Regarding installation procedures, I wish that ocamlfind (ie findlib)
becomes part of standard Ocaml. Or otherwise, so similar tools.

I also wish that the standard Ocaml distribution provides the ability
to query the actual installation option, in particular: does Ocaml has
been compiled with pthread support (etc..)?

Regards.

-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Brian Hurt]

Thinking about it some more, I think I'm comming down opposed to a 
CPAN-style library.

At my previous job we had a large app written in Perl (~5 man-years of
development effort) which was dependent upon several CPAN libraries.  
Installing this application was *ahem* interesting.  Part of the trick was
just remembering which libraries were needed.  Installing a single CPAN
module is easy.  Installing 30 (and then backtracking to remember which
ones you missed) is a chore.  Installing a single monolithic block (or a
small number of semilithic blocks) is easier.

Versioning was also a problem.  Hopefully this was more of a language 
issue than a module issue, but it's a relevent fear.  I remember they were 
having to downgrade the perls that came with newer redhats because several 
of the libraries hadn't yet been upgraded to the newer version (or, in one 
memorable case, had been ugraded so that it worked with version X and 
version X+2, but not version X+1, which was, natch, the version RH shipped 
with).  A monolithic library, under a more central management, would make 
conformance easier to enforce.

Brian

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

Re: [Caml-list] Alternative proposal: COAN

[Brian Hurt]

Blech.  This was supposed to go to the other list.  Sorry.

I *am* trying to redirect discussion there.  Please reply to me on the 
other list.

Brian


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

Re: [Caml-list] Alternative proposal: COAN

[Benjamin C. Pierce]

> Blech.  This was supposed to go to the other list.  Sorry.
> 
> I *am* trying to redirect discussion there.  Please reply to me on the 
> other list.

Can we please keep the COAN discussion on the main caml-list?  I think
it's of general interest (as opposed to details of standard library
extensions and comparisons of the merits of different licences, which I'm
happy to have somewhere else).  And I really don't want to subscribe to
another list.

      - Benjamin

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

Re: [Caml-list] Alternative proposal: COAN

[roberto]

I think I cannot avoid to agree with what Brian puts forward: I had a similar
experience installyng Sympa (a Majordomo replacement written in Perl by a French
institution, which, by the way, is a remarkable piece of software), where I
spent a day trying to understand why the ludicrous install procedure was
throwing on me zillions of packages, including a rebuild of Perl 5.8.

But it is probably necessary here to clearly separate the different issues...
at first sight, I see:

- centralized repository:

    Issue: we want some central place where to look for Ocaml code
           without resorting to google
    Solution: this can be done in a pretty simple way, and the Humps are a step
              in this direction, but they are not yet a centralized repository
              (code is still spread around the world: it would be nice if we
               had a central mirror of all the code, instead of only pointer).

- easy installation:

    Issue: I want to run advi to give flashy LaTeX presentation, and I want to
           just get a binary for my nice OS I love so much, without having to
           recompile anything

    Solution: well, either there is a monolithic binary already ready for you,
           or you will need to recompile something. In this last case, if the
           standard library (or extended standard library) is complete enough,
           maybe a simple "make" will do (this is what I really really like of
           many old Ocaml programs, or actually, about CamlLight and Ocaml itself :-) ).

           Notice that this is quite similar to the approach used by NeXT in the good
           'ole days when they gave you a big shared library (the standard
           library) and all the rest was statically linked, to prevent you
           from shooting yourself in the foot.
 
           But Ocaml is going mainstream, so the chances of a monolithic library
           good for everything seem, IMHO, low, and it is wise to consider the
           third issue...

- dependency tracking:

    Issue: we would really really like to avoid reading "README"s
           to discover the zillion packages on which the next future generation Ocaml
           killer application will depend. Just type "install XYZ" and that's it.

    Solution: not so easy... because all this really requires:

      - a standard for declaring dependencies (XYZ depends on ZWT, WTX and WXW)
      - a standard for managing versions (XYZ v n.m depends on ZWT v >= n'.m' etc.)
      - a standard for fetching sources/binaries from repositories
      - a standard for rebuilding/recompiling packages

      But, wait, after all, this is pretty similar to what is done by apt in the Debian
      linux distribution! Probably one should have a look at apt as a starting
      point. I would be interested to have the feelings of the various
      people here that do Debian packages on the suitability of the apt tools to
      handle this kind of issues in the Ocaml world.

Sorry for being long ...

>>>>> "Brian" == Brian Hurt <brian.hurt@qlogic.com> writes:

    Brian> Thinking about it some more, I think I'm comming down opposed to a
    Brian> CPAN-style library.

[snip]

    Brian> Installing this application was *ahem* interesting.
[snip]
    Brian> Versioning was also a problem. [snip] A monolithic library,
    Brian> under a more central management, would make conformance easier to
    Brian> enforce.

--Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur (on leave at/detache a INRIA Roquencourt)
PPS                             E-mail: roberto@dicosmo.org
Universite Paris VII            WWW  : http://www.dicosmo.org
Case 7014                       Tel  : ++33-(1)-39 63 51 97
2, place Jussieu                Fax  : ++33-(1)-44 27 68 49
F-75251 Paris Cedex 05
FRANCE.                  MIME/NextMail accepted
------------------------------------------------------------------
Office location:

Paris VII	 		INRIA Roquencourt
 
Bureau 6C14 (6th floor)         Bureau 13, Batiment 5
175, rue du Chevaleret, XIII    Domaine de Voluceau
Metro Chevaleret, ligne 6       Roquencourt
------------------------------------------------------------------                                                 
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Tue, Feb 25, 2003 at 11:54:50AM +0100, roberto@dicosmo.org wrote:
> - easy installation:
> 
>     Issue: I want to run advi to give flashy LaTeX presentation, and I want to
>            just get a binary for my nice OS I love so much, without having to
>            recompile anything

BTW, i have much been thinking of generating a version of knoppix
(single CD debian distros, which boots directly from the CD), which
would include advi and all other parts needed for it to run, and maybe
have a script that would generate a CD image including your
presentation.

Such a CD should boot on every hardware out there without much problems,
so you would just need to go to your conference insert the CD and reboot
the box.

As for other stuff, well, you could just use debian and use our packages
which solve most of the dependency issues, with more to come in my next
upload of the ocaml_packaging_policy. I think you could also use the
mingw cross compiler or something such to automatically build win32
packages out of the debian packages, but i didn't look much into this.

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

Re: [Caml-list] Alternative proposal: COAN

[roberto]

Dear Sven,
     actually, in the latest version of DemoLinux (a Live CD pretty
older than Knoppix, distribution-independent, even if now based on
Debian) distributed with the CD of free software from
Inria, there is advi, whyzzitex and ocaml preinstalled and
you are pretty welcome to download it from www.demolinux.org
(I had to edit a bit your packages to make it suitable for the Debian
installed in DemoLinux, but it was rather easy work...)

Now, it is a long time since DemoLinux did not go through a major upgrade,
partly because I still dream of rewriting all the configuration/detection/
installation stuff in Ocaml, but I did not convince myself to really start
the real work... But if some people is interested ... :-)

--Roberto


>>>>> "Sven" == Sven Luther <luther@dpt-info.u-strasbg.fr> writes:

    Sven> On Tue, Feb 25, 2003 at 11:54:50AM +0100, roberto@dicosmo.org wrote:
    >> - easy installation:
    >> 
    >> Issue: I want to run advi to give flashy LaTeX presentation, and I want
    >> to just get a binary for my nice OS I love so much, without having to
    >> recompile anything

    Sven> BTW, i have much been thinking of generating a version of knoppix
    Sven> (single CD debian distros, which boots directly from the CD), which
    Sven> would include advi and all other parts needed for it to run, and maybe
    Sven> have a script that would generate a CD image including your
    Sven> presentation.

    Sven> Such a CD should boot on every hardware out there without much
    Sven> problems, so you would just need to go to your conference insert the
    Sven> CD and reboot the box.

    Sven> As for other stuff, well, you could just use debian and use our
    Sven> packages which solve most of the dependency issues, with more to come
    Sven> in my next upload of the ocaml_packaging_policy. I think you could
    Sven> also use the mingw cross compiler or something such to automatically
    Sven> build win32 packages out of the debian packages, but i didn't look
    Sven> much into this.

    Sven> Friendly,

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

-- 
--Roberto Di Cosmo
 
------------------------------------------------------------------
Professeur (on leave at/detache a INRIA Roquencourt)
PPS                             E-mail: roberto@dicosmo.org
Universite Paris VII            WWW  : http://www.dicosmo.org
Case 7014                       Tel  : ++33-(1)-39 63 51 97
2, place Jussieu                Fax  : ++33-(1)-44 27 68 49
F-75251 Paris Cedex 05
FRANCE.                  MIME/NextMail accepted
------------------------------------------------------------------
Office location:

Paris VII	 		INRIA Roquencourt
 
Bureau 6C14 (6th floor)         Bureau 13, Batiment 5
175, rue du Chevaleret, XIII    Domaine de Voluceau
Metro Chevaleret, ligne 6       Roquencourt
------------------------------------------------------------------                                                 
-------------------
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

RE: [Caml-list] Alternative proposal: COAN

[MikhailFedotov]

Hi!

> But it is probably necessary here to clearly separate the
> different issues... at first sight, I see:

[skipped]

I think it is a good idea to learn how Jakarta project on www.apache.org
is organized.

It is based on centralized repository. There is a tool that runs several
times per day and builds every project (latest dev version) to ensure
that they are building correctly. Dependency tracking is implemented
via build files (which are much similar to makefiles).

So, if there would be centralized repository for ocaml projects, it
would
be easier to keep them working together.

There are many questions on how to do it exactly, but the most
important is the following: first, it is unknown if ocaml developers
would like to support centralized repository like ApacheGroup does;
and second, it is unknown if existing projects will decide to move into
this repository, like many open-sources java projects are moving under
Apache umbrella.

ps. Apache group projects also share the same license. Less time spent
on legal stuff and more on development.

Mikhail


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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Tue, Feb 25, 2003 at 02:36:21PM +0100, roberto@dicosmo.org wrote:
> Dear Sven,
>      actually, in the latest version of DemoLinux (a Live CD pretty
> older than Knoppix, distribution-independent, even if now based on
> Debian) distributed with the CD of free software from
> Inria, there is advi, whyzzitex and ocaml preinstalled and
> you are pretty welcome to download it from www.demolinux.org
> (I had to edit a bit your packages to make it suitable for the Debian
> installed in DemoLinux, but it was rather easy work...)

Ah, i didn't know that, i will give it a try. It will have the older
versions though, i guess.

> Now, it is a long time since DemoLinux did not go through a major upgrade,
> partly because I still dream of rewriting all the configuration/detection/
> installation stuff in Ocaml, but I did not convince myself to really start
> the real work... But if some people is interested ... :-)

I am not really sure it is worth it.

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

Re: [Caml-list] Alternative proposal: COAN

[Eric C. Cooper]

On Tue, Feb 25, 2003 at 11:54:50AM +0100, roberto@dicosmo.org wrote:
> I think I cannot avoid to agree with what Brian puts forward: I had
> a similar experience installyng Sympa (a Majordomo replacement
> written in Perl by a French institution, which, by the way, is a
> remarkable piece of software), where I spent a day trying to
> understand why the ludicrous install procedure was throwing on me
> zillions of packages, including a rebuild of Perl 5.8.
> ...
> But, wait, after all, this is pretty similar to what is done by apt
> in the Debian linux distribution! Probably one should have a look at
> apt as a starting point. I would be interested to have the feelings
> of the various people here that do Debian packages on the
> suitability of the apt tools to handle this kind of issues in the
> Ocaml world.

I have gotten into the habit of using apt-get for all the Perl modules
I need to install, rather than going to CPAN.  The Debian maintainers
have done the hard work of specifying the dependencies, install
scripts, etc. so that it's easy to install and uninstall them.  I'm
sure I get only a small subset of CPAN that way, but the quality
control has been worth it, and I haven't needed anything that wasn't
already Debianized.

This is mainly valuable because it is the *same* apt-get tool used for
everything on the system, not a parallel tool just for Perl.  It makes
it easier for Perl applications to be mainstream rather than marginal,
because other packages can easily and robustly specify dependencies on
the Perl apps.

For these reasons, a parallel tool just for OCaml would be less useful than
packaging the relevant libraries as Debian packages (like Sven Luther and
others have done -- thanks!)  But that doesn't help non-Debian OCaml users.

-- 
Eric C. Cooper          e c c @ c m u . e d u
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Michal Moskal]

On Tue, Feb 25, 2003 at 12:15:50PM -0500, Eric C. Cooper wrote:
> I have gotten into the habit of using apt-get for all the Perl modules
> I need to install, rather than going to CPAN.  The Debian maintainers
> have done the hard work of specifying the dependencies, install
> scripts, etc. so that it's easy to install and uninstall them.  I'm
> sure I get only a small subset of CPAN that way, but the quality
> control has been worth it, and I haven't needed anything that wasn't
> already Debianized.
> 
> This is mainly valuable because it is the *same* apt-get tool used for
> everything on the system, not a parallel tool just for Perl.  It makes
> it easier for Perl applications to be mainstream rather than marginal,
> because other packages can easily and robustly specify dependencies on
> the Perl apps.
> 
> For these reasons, a parallel tool just for OCaml would be less useful than
> packaging the relevant libraries as Debian packages (like Sven Luther and
> others have done -- thanks!)  But that doesn't help non-Debian OCaml users.

Look how much perl modules is debianized and how much ocaml modules is.
I can only give figures for PLD (rpms): ocaml - 29, perl - 961. Now this
is not mainly because there is lot more perl modules available. The main
problem is that for average perl package all you need to do to put it
into rpm is:

	%build
	%{__perl} Makefile.PL
	%{__make}

	%install
	rm -rf $RPM_BUILD_ROOT

	%{__make} install DESTDIR=$RPM_BUILD_ROOT

CPAN modules are standardized. That's the main advantage of them. We need
this kind of stuff for ocaml. 

What we should standardize? IMHO:

1. Naming conventions. Maybe some guidelines for package names. Anyway
   for package foo, version 1.2.3:
     - source tarball should be foo-1.2.3.tar.gz
     - it should unpack all it's files into foo-1.2.3 directory
   (these are good GNU practices anyway)

2. Build procedure. We can either use OCamlMakefile, ocamake, or
   some ocaml script. But make it standard for all COAN packages.
   Preferably makefiles should be generated or build process should be
   performed by a special tool, so it is possible for example to add
   DESTDIR support, or shared library support if it's added to ocaml,
   in one place instead of hundreds of COAN packages.

   In any event building COAN package should be matter of one command.
   And it should be the same command for all COAN packages.

3. Installation. IMHO packages should be installed to `ocamlc
   -where`/package-name. Installation tool, whatever it is,
   should support DESTDIR (i.e. specifying fake root directory).

4. Documentation. But this should be easy -- just use ocamldoc, 
   and maybe some additional files (in pkg-version/doc/).

5. Enforce META files for findlib?

6. Maybe some metafile describing package and dependencies? 
   From which .spec for rpm and makefile rules for debs could 
   be generated. Preferably in XML. Example:

<pkg name="mysql" 
     version="1.2.3" 
     url="http://foobar.com/mysql-ocaml/">
  <short>MySQL bindings</short>
  <short lang="pl">Wiazania MySQL</short>
  <long>
    This package provides bindings to MySQL server, blah... blah...
    <!-- 10 lines or so -->
  </long>
  <long lang="de"> .... </long>
  <license>BSD-like</license>
  <!-- We need to standardize this as well. -->
  <category>Bindings/Database</category>
  <depends-on>
    <!-- packages from COAN: -->
    <coan-pkg name="foobar" version-not-less-then="1.23"/>
    <!-- maybe name="foobar >= 1.23" will be better? -->
    <coan-pkg name="foobar-baz" version-equal="1.23"/>
    <!-- system packages: -->
    <system-pkg name="ocaml" version-not-less-then="3.06"/>
    <!-- not mysql-devel or mysql-dev, just mainstream name -->
    <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
  </depends-on>
</pkg>

Note that this does not overlap much with META-files. Intention is that
this meta.xml file should be distributed with sources, not generated
during build. META file might need to be generated (for example to embed
C linker option in it).

Just my 0.02PLN, mainly from packager point of view. In case I'm being
too rpmcentric, Sven please correct me :-)

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

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

Re: [Caml-list] Alternative proposal: COAN

[Lauri Alanko]

When Haskell got to the same situation (ie. people began to collect
miscellaneous libraries into a coherent whole), one of the first things
to be done was to extend the module system of the language to
hierarchical namespaces:

<http://www.haskell.org/~simonmar/libraries/libraries.html>

This sort of thing is done in Java, it is done in Perl, and it probably
ought to be done in just about any language that plans to support lots
of libraries. Naming conflicts are icky. I would very much like O'Caml
to have hierarchical namespaces as well.

The standard hierarchy layout presented in the above URL is probably
also worth pondering.


Lauri Alanko
la@iki.fi
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Tue, Feb 25, 2003 at 10:48:33PM +0100, Michal Moskal wrote:
> On Tue, Feb 25, 2003 at 12:15:50PM -0500, Eric C. Cooper wrote:
> > I have gotten into the habit of using apt-get for all the Perl modules
> > I need to install, rather than going to CPAN.  The Debian maintainers
> > have done the hard work of specifying the dependencies, install
> > scripts, etc. so that it's easy to install and uninstall them.  I'm
> > sure I get only a small subset of CPAN that way, but the quality
> > control has been worth it, and I haven't needed anything that wasn't
> > already Debianized.
> > 
> > This is mainly valuable because it is the *same* apt-get tool used for
> > everything on the system, not a parallel tool just for Perl.  It makes
> > it easier for Perl applications to be mainstream rather than marginal,
> > because other packages can easily and robustly specify dependencies on
> > the Perl apps.
> > 
> > For these reasons, a parallel tool just for OCaml would be less useful than
> > packaging the relevant libraries as Debian packages (like Sven Luther and
> > others have done -- thanks!)  But that doesn't help non-Debian OCaml users.
> 
> 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.

> CPAN modules are standardized. That's the main advantage of them. We need
> this kind of stuff for ocaml. 
> 
> What we should standardize? IMHO:
> 
> 1. Naming conventions. Maybe some guidelines for package names. Anyway
>    for package foo, version 1.2.3:
>      - source tarball should be foo-1.2.3.tar.gz
>      - it should unpack all it's files into foo-1.2.3 directory
>    (these are good GNU practices anyway)

Note that debian packaging tools can handle unstandard source tarballs
without much problems, nice so we don't need to rebuild the tarball,
which modifies its md5sum.

> 2. Build procedure. We can either use OCamlMakefile, ocamake, or
>    some ocaml script. But make it standard for all COAN packages.
>    Preferably makefiles should be generated or build process should be
>    performed by a special tool, so it is possible for example to add
>    DESTDIR support, or shared library support if it's added to ocaml,
>    in one place instead of hundreds of COAN packages.
> 
>    In any event building COAN package should be matter of one command.
>    And it should be the same command for all COAN packages.

Yes, DESTDIR support is a pain to add to each ocaml package. I don't
feel much like forcing a standardized build process though, not everyone
likes the same, as long as it supports changing the DESTDIR and has a
fairly easy build process, along the lines of configure, make, make
install. configure can be by editing a config file or preferably by a
configure script or a configure makefile target.

> 3. Installation. IMHO packages should be installed to `ocamlc
>    -where`/package-name. Installation tool, whatever it is,
>    should support DESTDIR (i.e. specifying fake root directory).

Note, that i strongly advocate having two libdir directories, one,
/usr/lib/ocaml/<version_number>, for packages from the distrib, and the
second, /usr/local/lib/ocaml/<version_number>, for locally installed
packages. The first libdir would be given by -distwhere, and the second
by -where. findlib and such would default to the locale directory, but
could be overriden by the package maintainer.

> 4. Documentation. But this should be easy -- just use ocamldoc, 
>    and maybe some additional files (in pkg-version/doc/).
> 
> 5. Enforce META files for findlib?
>
> 6. Maybe some metafile describing package and dependencies? 
>    From which .spec for rpm and makefile rules for debs could 
>    be generated. Preferably in XML. Example:

Err, you are speaking about the debian/control files, we don't use
makefiles for such kind of information, only for building the package.

> <pkg name="mysql" 
>      version="1.2.3" 
>      url="http://foobar.com/mysql-ocaml/">
>   <short>MySQL bindings</short>
>   <short lang="pl">Wiazania MySQL</short>
>   <long>
>     This package provides bindings to MySQL server, blah... blah...
>     <!-- 10 lines or so -->
>   </long>
>   <long lang="de"> .... </long>
>   <license>BSD-like</license>
>   <!-- We need to standardize this as well. -->
>   <category>Bindings/Database</category>
>   <depends-on>
>     <!-- packages from COAN: -->
>     <coan-pkg name="foobar" version-not-less-then="1.23"/>
>     <!-- maybe name="foobar >= 1.23" will be better? -->
>     <coan-pkg name="foobar-baz" version-equal="1.23"/>
>     <!-- system packages: -->
>     <system-pkg name="ocaml" version-not-less-then="3.06"/>
>     <!-- not mysql-devel or mysql-dev, just mainstream name -->
>     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
>   </depends-on>
> </pkg>

Well, first, i personnally don't like CML, but seriously, don't you
think that this format is a bit oververbose and incomprehensible for
just plain dependencies ?

For debian, we just have dependencies and build dependencies. Each of
those are listed in a field of the debian/control file, some of which
are dynamically generated at build time. As an example, lablgtk has the
following :

(* for the source package *)
Build-Depends: debhelper (>> 3.0.0), ocaml-3.06-1, libncurses5-dev, xlibs|xlib6g, debhelper, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3), librsvg2-dev
...

(* for the runtime package *)
Depends: ocaml-base-3.06-1,  ${shlibs:Depends}
...
(* for the developpment package *)
Depends: liblablgtk2-ocaml (= ${Source-Version}), ocaml-3.06-1, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3)

This, with the Provides, Conflicts, Recomend and Suggest, is enough for
handling dependencies, and much more easier to understand and work with
than the XML horror you where suggesting.

> Note that this does not overlap much with META-files. Intention is that
> this meta.xml file should be distributed with sources, not generated
> during build. META file might need to be generated (for example to embed
> C linker option in it).
> 
> Just my 0.02PLN, mainly from packager point of view. In case I'm being
> too rpmcentric, Sven please correct me :-)

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

Re: [Caml-list] Alternative proposal: COAN

[Michal Moskal]

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.

> > CPAN modules are standardized. That's the main advantage of them. We need
> > this kind of stuff for ocaml. 
> > 
> > What we should standardize? IMHO:
> > 
> > 1. Naming conventions. Maybe some guidelines for package names. Anyway
> >    for package foo, version 1.2.3:
> >      - source tarball should be foo-1.2.3.tar.gz
> >      - it should unpack all it's files into foo-1.2.3 directory
> >    (these are good GNU practices anyway)
> 
> Note that debian packaging tools can handle unstandard source tarballs
> without much problems, nice so we don't need to rebuild the tarball,
> which modifies its md5sum.

Yes, sure, rpm can also handle it. But it's still better to have
it in the same place in each package, isn't it?

> > 2. Build procedure. We can either use OCamlMakefile, ocamake, or
> >    some ocaml script. But make it standard for all COAN packages.
> >    Preferably makefiles should be generated or build process should be
> >    performed by a special tool, so it is possible for example to add
> >    DESTDIR support, or shared library support if it's added to ocaml,
> >    in one place instead of hundreds of COAN packages.
> > 
> >    In any event building COAN package should be matter of one command.
> >    And it should be the same command for all COAN packages.
> 
> Yes, DESTDIR support is a pain to add to each ocaml package. I don't
> feel much like forcing a standardized build process though, not everyone
> likes the same, as long as it supports changing the DESTDIR and has a
> fairly easy build process, along the lines of configure, make, make
> install. configure can be by editing a config file or preferably by a
> configure script or a configure makefile target.

Ok, forcing isn't exactly the best way to go. Maybe the best way would
be to prepare example/template package? Then people will probably copy
from it.

> > 3. Installation. IMHO packages should be installed to `ocamlc
> >    -where`/package-name. Installation tool, whatever it is,
> >    should support DESTDIR (i.e. specifying fake root directory).
> 
> Note, that i strongly advocate having two libdir directories, one,
> /usr/lib/ocaml/<version_number>, for packages from the distrib, and the
> second, /usr/local/lib/ocaml/<version_number>, for locally installed
> packages. The first libdir would be given by -distwhere, and the second
> by -where. findlib and such would default to the locale directory, but
> could be overriden by the package maintainer.

Hm... What if ocaml itself is installed in /usr/local? But I believe
you're right here.

> > 4. Documentation. But this should be easy -- just use ocamldoc, 
> >    and maybe some additional files (in pkg-version/doc/).
> > 
> > 5. Enforce META files for findlib?
> >
> > 6. Maybe some metafile describing package and dependencies? 
> >    From which .spec for rpm and makefile rules for debs could 
> >    be generated. Preferably in XML. Example:
> 
> Err, you are speaking about the debian/control files, we don't use
> makefiles for such kind of information, only for building the package.

Yes.

> > <pkg name="mysql" 
> >      version="1.2.3" 
> >      url="http://foobar.com/mysql-ocaml/">
> >   <short>MySQL bindings</short>
> >   <short lang="pl">Wiazania MySQL</short>
> >   <long>
> >     This package provides bindings to MySQL server, blah... blah...
> >     <!-- 10 lines or so -->
> >   </long>
> >   <long lang="de"> .... </long>
> >   <license>BSD-like</license>
> >   <!-- We need to standardize this as well. -->
> >   <category>Bindings/Database</category>
> >   <depends-on>
> >     <!-- packages from COAN: -->
> >     <coan-pkg name="foobar" version-not-less-then="1.23"/>
> >     <!-- maybe name="foobar >= 1.23" will be better? -->
> >     <coan-pkg name="foobar-baz" version-equal="1.23"/>
> >     <!-- system packages: -->
> >     <system-pkg name="ocaml" version-not-less-then="3.06"/>
> >     <!-- not mysql-devel or mysql-dev, just mainstream name -->
> >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
> >   </depends-on>
> > </pkg>
> 
> Well, first, i personnally don't like CML, but seriously, don't you
> think that this format is a bit oververbose and incomprehensible for
> just plain dependencies ?

The nice thing about XML is that there are already tools to parse and
transform it. And that's why I don't believe it's an overkill.

> For debian, we just have dependencies and build dependencies. Each of
> those are listed in a field of the debian/control file, some of which
> are dynamically generated at build time. As an example, lablgtk has the
> following :
> 
> (* for the source package *)
> Build-Depends: debhelper (>> 3.0.0), ocaml-3.06-1, libncurses5-dev, xlibs|xlib6g, debhelper, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3), librsvg2-dev
> ...
> 
> (* for the runtime package *)
> Depends: ocaml-base-3.06-1,  ${shlibs:Depends}
> ...
> (* for the developpment package *)
> Depends: liblablgtk2-ocaml (= ${Source-Version}), ocaml-3.06-1, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3)

This is the same as in rpm. But this kind of stuff can be generated from
<depends-on /> I gave above (with little human intervention).

> This, with the Provides, Conflicts, Recomend and Suggest, is enough for
> handling dependencies, and much more easier to understand and work with
> than the XML horror you where suggesting.

> >     <coan-pkg name="foobar" version-not-less-then="1.23"/>

---> Depends: foobar (>= 1.23)

> >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>

---> Build-Depends: mysql-dev (>= 1.2.3)

This is simple, you just need to look at it for a moment.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

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
also, it is just the ones that have broken or short-sighted build
process, like those thinking everyone support the native-code compiler,
or that forget about the DESTDIR. 

Mostly my build recomendations would be :

  o support a DESTDIR to install in another directory than you built for.

  o support to build either the bytecode or the native code compiler,
    having an option to rename both versions as the same name. I build
    packages containing both sometimes.

I don't think really more is needed, apart from the standard libdir
detection or such.

> > > 2. Build procedure. We can either use OCamlMakefile, ocamake, or
> > >    some ocaml script. But make it standard for all COAN packages.
> > >    Preferably makefiles should be generated or build process should be
> > >    performed by a special tool, so it is possible for example to add
> > >    DESTDIR support, or shared library support if it's added to ocaml,
> > >    in one place instead of hundreds of COAN packages.
> > > 
> > >    In any event building COAN package should be matter of one command.
> > >    And it should be the same command for all COAN packages.
> > 
> > Yes, DESTDIR support is a pain to add to each ocaml package. I don't
> > feel much like forcing a standardized build process though, not everyone
> > likes the same, as long as it supports changing the DESTDIR and has a
> > fairly easy build process, along the lines of configure, make, make
> > install. configure can be by editing a config file or preferably by a
> > configure script or a configure makefile target.
> 
> Ok, forcing isn't exactly the best way to go. Maybe the best way would
> be to prepare example/template package? Then people will probably copy
> from it.

There is already example OCAMLMKFILE, but i think some people (like
myself) don't like it and prefer to use their own makefiles. Also some
people may want to use findlib and other not. There is no problem with
that, as long as the resulting build system meets certain criterias,
like the above.

> 
> > > 3. Installation. IMHO packages should be installed to `ocamlc
> > >    -where`/package-name. Installation tool, whatever it is,
> > >    should support DESTDIR (i.e. specifying fake root directory).
> > 
> > Note, that i strongly advocate having two libdir directories, one,
> > /usr/lib/ocaml/<version_number>, for packages from the distrib, and the
> > second, /usr/local/lib/ocaml/<version_number>, for locally installed
> > packages. The first libdir would be given by -distwhere, and the second
> > by -where. findlib and such would default to the locale directory, but
> > could be overriden by the package maintainer.
> 
> Hm... What if ocaml itself is installed in /usr/local? But I believe
> you're right here.

Well, that is the users problem. In debian, and i guess in other
distribs also, the filesystem is mostly reserved for the package
manager, and therefor cannot be used by the user. The only exception are
/usr/local and the user home directory, /home/jo_user. And /etc where
the user may modify configuration files.

Therefor every user installed module should either stay in his
homedirectory or go into /usr/local if it is to be installed
system-wide. Therefor ocaml should be able to look into at least 3
different places for its modules, which is not possible now.

So, until ocaml get OCAMLPATH support, there is nothing we can do about
it.

> > > 4. Documentation. But this should be easy -- just use ocamldoc, 
> > >    and maybe some additional files (in pkg-version/doc/).
> > > 
> > > 5. Enforce META files for findlib?
> > >
> > > 6. Maybe some metafile describing package and dependencies? 
> > >    From which .spec for rpm and makefile rules for debs could 
> > >    be generated. Preferably in XML. Example:
> > 
> > Err, you are speaking about the debian/control files, we don't use
> > makefiles for such kind of information, only for building the package.
> 
> Yes.
> 
> > > <pkg name="mysql" 
> > >      version="1.2.3" 
> > >      url="http://foobar.com/mysql-ocaml/">
> > >   <short>MySQL bindings</short>
> > >   <short lang="pl">Wiazania MySQL</short>
> > >   <long>
> > >     This package provides bindings to MySQL server, blah... blah...
> > >     <!-- 10 lines or so -->
> > >   </long>
> > >   <long lang="de"> .... </long>
> > >   <license>BSD-like</license>
> > >   <!-- We need to standardize this as well. -->
> > >   <category>Bindings/Database</category>
> > >   <depends-on>
> > >     <!-- packages from COAN: -->
> > >     <coan-pkg name="foobar" version-not-less-then="1.23"/>
> > >     <!-- maybe name="foobar >= 1.23" will be better? -->
> > >     <coan-pkg name="foobar-baz" version-equal="1.23"/>
> > >     <!-- system packages: -->
> > >     <system-pkg name="ocaml" version-not-less-then="3.06"/>
> > >     <!-- not mysql-devel or mysql-dev, just mainstream name -->
> > >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
> > >   </depends-on>
> > > </pkg>
> > 
> > Well, first, i personnally don't like CML, but seriously, don't you
> > think that this format is a bit oververbose and incomprehensible for
> > just plain dependencies ?
> 
> The nice thing about XML is that there are already tools to parse and
> transform it. And that's why I don't believe it's an overkill.

Well, but at the expense of human readability, which is i think a loss.
Anyway, i think debian packages will not be automatized, or at least the
maintainer will need to check if the package is not doing some strange
things or such. So, something easy to cut&paste will have my preference
over the nightmarish stuff you proposed. Also remember that packages may
have different names on different distribs or something such.

> > For debian, we just have dependencies and build dependencies. Each of
> > those are listed in a field of the debian/control file, some of which
> > are dynamically generated at build time. As an example, lablgtk has the
> > following :
> > 
> > (* for the source package *)
> > Build-Depends: debhelper (>> 3.0.0), ocaml-3.06-1, libncurses5-dev, xlibs|xlib6g, debhelper, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3), librsvg2-dev
> > ...
> > 
> > (* for the runtime package *)
> > Depends: ocaml-base-3.06-1,  ${shlibs:Depends}
> > ...
> > (* for the developpment package *)
> > Depends: liblablgtk2-ocaml (= ${Source-Version}), ocaml-3.06-1, libgtk2.0-dev, libgtkgl2.0-dev, libglade2-dev, liblablgl-ocaml-dev (>= 0.99-3)
> 
> This is the same as in rpm. But this kind of stuff can be generated from
> <depends-on /> I gave above (with little human intervention).

Sure, just not easily with vi.

> > This, with the Provides, Conflicts, Recomend and Suggest, is enough for
> > handling dependencies, and much more easier to understand and work with
> > than the XML horror you where suggesting.
> 
> > >     <coan-pkg name="foobar" version-not-less-then="1.23"/>
> 
> ---> Depends: foobar (>= 1.23)
> 
> > >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
> 
> ---> Build-Depends: mysql-dev (>= 1.2.3)
> 
> This is simple, you just need to look at it for a moment.

Unless the distib has foobar1 and foobar1.2 available, unless they
changed foobar into libfoo-dev or other something such. There is human
intervention needed to check this, so at least make it readable.

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

Re: [Caml-list] Alternative proposal: COAN

[Michal Moskal]

On Wed, Feb 26, 2003 at 11:11:50AM +0100, Sven Luther wrote:
> Mostly my build recomendations would be :
> 
>   o support a DESTDIR to install in another directory than you built for.
> 
>   o support to build either the bytecode or the native code compiler,
>     having an option to rename both versions as the same name. I build
>     packages containing both sometimes.

    o support passing user-defined CFLAGS, CC
  
[snip]
> > Ok, forcing isn't exactly the best way to go. Maybe the best way would
> > be to prepare example/template package? Then people will probably copy
> > from it.
> 
> There is already example OCAMLMKFILE, but i think some people (like
> myself) don't like it and prefer to use their own makefiles. Also some
> people may want to use findlib and other not. There is no problem with
> that, as long as the resulting build system meets certain criterias,
> like the above.

Ok, as long as we define the criteria clearly. But still template
wouldn't be that bad idea.

[snip]
> > > This, with the Provides, Conflicts, Recomend and Suggest, is enough for
> > > handling dependencies, and much more easier to understand and work with
> > > than the XML horror you where suggesting.
> > 
> > > >     <coan-pkg name="foobar" version-not-less-then="1.23"/>
> > 
> > ---> Depends: foobar (>= 1.23)
> > 
> > > >     <system-pkg name="MySQL" version-not-less-then="1.2.3"/>
> > 
> > ---> Build-Depends: mysql-dev (>= 1.2.3)
> > 
> > This is simple, you just need to look at it for a moment.
> 
> Unless the distib has foobar1 and foobar1.2 available, unless they
> changed foobar into libfoo-dev or other something such. There is human
> intervention needed to check this, so at least make it readable.

Ok, you win :-)

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

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

Re: [Caml-list] Alternative proposal: COAN

[Olivier Andrieu]

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

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.

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Wed, Feb 26, 2003 at 11:26:18AM +0100, Michal Moskal wrote:
> On Wed, Feb 26, 2003 at 11:11:50AM +0100, Sven Luther wrote:
> > Mostly my build recomendations would be :
> > 
> >   o support a DESTDIR to install in another directory than you built for.
> > 
> >   o support to build either the bytecode or the native code compiler,
> >     having an option to rename both versions as the same name. I build
> >     packages containing both sometimes.
> 
>     o support passing user-defined CFLAGS, CC

Whatever for ? 

Mmm, i suppose these are for the libraries building C stubs, only, right ?

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Wed, Feb 26, 2003 at 12:14:13AM +0200, Lauri Alanko wrote:
> When Haskell got to the same situation (ie. people began to collect
> miscellaneous libraries into a coherent whole), one of the first things
> to be done was to extend the module system of the language to
> hierarchical namespaces:
> 
> <http://www.haskell.org/~simonmar/libraries/libraries.html>
> 
> This sort of thing is done in Java, it is done in Perl, and it probably
> ought to be done in just about any language that plans to support lots
> of libraries. Naming conflicts are icky. I would very much like O'Caml
> to have hierarchical namespaces as well.
> 
> The standard hierarchy layout presented in the above URL is probably
> also worth pondering.

This is already present and doable, we just need to use the -pack
option, which was added exactly for that. That and the module system
should be enough for any namespace handling we want to do.

Sadly, the current -pack option has still some problems on some
plateforms, and nobody really uses it.

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

Re: [Caml-list] Alternative proposal: COAN

[Nicolas Cannasse]

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

Will I need to install wonderful programming langages such as perl or python
on my Windows box ? Without any flames, why are always unix users wants to
make things so complicated ? :)
I will much more prefer something like :

ocaml Makefile.ml

And then the build system will be multiplatform since you're using ocaml...
assuming that're using Unix functions supported on both MacOS & Windows (
theses are documented ) and not calling any command-line function (nor using
paths such as /user/ocaml/and_much_more ).

I think the best is to have such a fully-caml-written tool for both
compilation (ocamake is already doing this, but right now there is no
support for C stubs compilation) and installation which does not rely on
OS-specific problems such as path organisation and so on... Such problems
could be handled in the "install" tool configuration file.

Nicolas Cannasse

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

Re: [Caml-list] Alternative proposal: COAN

[Nicolas Cannasse]

>     >> 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, 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
>     >>
>     >> 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.
>
>     NC> Will I need to install wonderful programming langages such as
>     NC> perl or python on my Windows box ? Without any flames, why are
>     NC> always unix users wants to make things so complicated ? :) I
>     NC> will much more prefer something like :
>
> Have you tried OCamlMakefile?  I gotta say -- I do a lot of weird
> stuff with Caml (preprocessing with a custom-written #define
> processor, amongst other weird stuff), and it's worked more-or-less
> like a charm.
>
> Indeed, I'd like to encourage others to use this puppy.  It *works*.
>
> A combination of OCamlMakefile, and "findlib" (Thanks, Gerd!!!!)
> really, really, really (did I mention really?) works to eliminate
> almost all my building and packaging hassles.
>
> I suspect that some sort of Makefile-generating facility, written in
> Caml (of course), combined with OcamlMakefile, and producing findlib
> modules, would be *near-ideal*.

No, I haven't used OCamlMakefile ( is is working with NMAKE ? )
And no, I don't think using findlib would be *near-ideal* since it isn't
ported on all platforms ( Windows at least, what about MacOs ? ).

Nicolas Cannasse

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

Re: [Caml-list] Alternative proposal: COAN

[Blair Zajac]

Lauri Alanko wrote:
> 
> When Haskell got to the same situation (ie. people began to collect
> miscellaneous libraries into a coherent whole), one of the first things
> to be done was to extend the module system of the language to
> hierarchical namespaces:
> 
> <http://www.haskell.org/~simonmar/libraries/libraries.html>
> 
> This sort of thing is done in Java, it is done in Perl, and it probably
> ought to be done in just about any language that plans to support lots
> of libraries. Naming conflicts are icky. I would very much like O'Caml
> to have hierarchical namespaces as well.

Perl doesn't have hierarchical namespaces.  There's no relationship
between a module OUTER and the module OUTER::INNER.

Given that Perl's done pretty well for itself in having a broad set of
modules with non-hierarchical namespaces, it doesn't look like a requirement
for Ocaml that it be modified to have hierarchical namespaces, while that
may be nice.

It seems to me we just need to put into place a standard package
namimg scheme, such as using `_' as a separator.

So instead of having a module Pxp_reader, would could have XML_PXP_Reader.

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Xavier Leroy]

> When Haskell got to the same situation (ie. people began to collect
> miscellaneous libraries into a coherent whole), one of the first things
> to be done was to extend the module system of the language to
> hierarchical namespaces: [...]
> This sort of thing is done in Java, it is done in Perl, and it probably
> ought to be done in just about any language that plans to support lots
> of libraries. Naming conflicts are icky. I would very much like O'Caml
> to have hierarchical namespaces as well.

Since day one, the OCaml module system has had "hierarchical"
namespaces in the form of nested modules.  Without sounding too cocky,
I'd say that ML doesn't have much to learn from Java or Perl in the
module department.

It is true that until recently OCaml didn't support separate
compilation of the submodules.  I.e. in order to present the user of
the library Lib with the hierarchical view Lib.A, Lib.B, etc,
the source had to be put in one file lib.ml.  Notice that this style
is perfectly workable with small to medium-sized libraries (see
my Cryptokit library for an example).

The '-pack' mechanism was introduced in 3.06 to support separate
compilation of the submodules.  Since it is a recent extension, it's
not yet stable enough to be used widely, but I expect this to change
with time.

- Xavier Leroy
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Sun, Feb 23, 2003 at 11:13:55AM -0500, Chet Murthy wrote:
> 
> >>>>> "NC" == Nicolas Cannasse <warplayer@free.fr> writes:
> 
>     NC> No, I haven't used OCamlMakefile ( is is working with NMAKE ? 
>     NC> ) And no, I don't think using findlib would be *near-ideal*
>     NC> since it isn't ported on all platforms ( Windows at least,
>     NC> what about MacOs ? ).
> 
> Ahhh ... Windows.  Oh, yeah, I guess, well, yeah, you're probably out
> of luck until somebody decides (like ActiveState did for Perl and
> Python - and note until they came along, that you were equally
> out-of-luck with Perl/Python) to port all the Caml tools nicely.
> 
> Until then, well, hmmmm ... I wonder how easy it would be to use
> Cygwin ...
> 
> Regardless, I think that solving this problem on UNIXes is already
> sufficiently valuable that more-or-less standardizing on OCamlMakefile
> and findlib would be a big step forward.

And as said, you could simply cross compile the windwos/mingw or
something such version, i think there is a cross compiling environment
for mingw available as a debian package. If i had time i would look if
it is possible to use it for crosscompiling my debian packages, that
would be nice :)))

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

Re: [Caml-list] Alternative proposal: COAN

[Damien Doligez]

On Thursday, February 27, 2003, at 05:54 AM, Nicolas Cannasse wrote:

> ported on all platforms ( Windows at least, what about MacOs ? ).

Mac OS X is a Unix like all other Unixes.  Mac OS 9 is irrelevant.
O'Caml 3.06 was never compiled for Mac OS 9, and no one has asked
for it yet.  We're seriously thinking of officially dropping support
for Mac OS 9.

-- Damien

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

[Caml-list] hierarchical modules

[John Carr]

> The '-pack' mechanism was introduced in 3.06 to support separate
> compilation of the submodules.  Since it is a recent extension, it's
> not yet stable enough to be used widely, but I expect this to change
> with time.

I meant to send this a long time ago, but I forgot.  These are three
reasons, from least to most important, why I think the -pack feature
implemented in ocaml 3.06 is not sufficient for hierarchical modules.

1. Compiled-in module and file names used for backtrace and assert are
not fully qualified when using -pack.  I have seen several ambiguous
backtraces when I used the same module name in two container modules
(i.e. used the same file name in two directories).

2. A module can not be -packed into a container module of the same name.

3. I want a separate interface file for the container module.  There
are two reasons for this:

(a) I want to have global, package, and module scope for names, including
making a type used by multiple modules within a directory opaque to other
code outside the directory.

(b) I don't want to recompile all my other code because a change to
the implementation of my module caused the container .cmi file to change.


I prefer specifying the container module name on the command line or
adding a "package" declaration to the source file as in Java.


	John Carr
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Jacques Garrigue]

The idea to simplify package management in ocaml is certainly a good
one. I personally agree very much with Roberto, at least on the issues.

From: roberto@dicosmo.org
> But it is probably necessary here to clearly separate the different issues...
> at first sight, I see:
> 
> - centralized repository:
>     Issue: we want some central place where to look for Ocaml code
>            without resorting to google
> - easy installation:
>     Issue: I want to run advi to give flashy LaTeX presentation, and I want t
>            just get a binary for my nice OS I love so much, without having to
>            recompile anything
> - dependency tracking:
>     Issue: we would really really like to avoid reading "README"s
>            to discover the zillion packages on which the next future
>            generation Ocaml killer application will depend. Just
>            type "install XYZ" and that's it. 

His conclusion was that apt-get (or something similar) is the way to
go. I agree mostly with this too, but my experience with BSD ports and
ocaml upgrading nightmares makes me differ on details.

* For me the central repository should not contain the source themselves.
  This was an error with the CDK: the distribution becomes huge, and
  it is very difficult for the maintainers to track changes 
  by developpers (who do not necessarily want to work in that
  repository, for evident practical reasons). Not speaking of
  licensing problems.
  With BSD ports, the central repository only contains metadata, that
  it a directory for each package, with its name, its dependencies,
  where to find it, how to configure and install it, and eventually
  some patches to make it fit in the system.
  The central repository would be a small one containing only
  metadata, updated often, eventually by authors themselves. Users who
  want newest stuff update by cvs, others get snapshots. Ideally some
  snapshots go through testing to become releases.
  The sources themselves are distributed as tarballs. This may be a
  good idea to replicate them on a few ftp servers, but there is no
  reason to make it compulsory.
  
* Easy installation means that you should be able to download, compile
  and install the desired ocaml program or library in one single
  command, including all the dependencies.
  This does not mean that a binary should be available. A binary will
  only work with a single version of ocaml and all dependencies, which
  is way too restrictive. Binaries may be provided on a by OS basis,
  but then it is much more comfortable for users to use the packaging
  system provided by the OS (tgz on FreeBSD, rpms on redhat, deb on
  debian, pkg on OSX, ??? on windows...) If the basic framework is
  right, that work should be easy enough.

* Dependency resolution and automatic recompilation/reinstallation is
  the core of the problem.
  When you modify an ocaml library, all its dependencies have to be
  recompiled. You certainly want to automate this, and have some
  foolproof system to be able to go back to a stable state. This is
  also an area where a bit of compiler "support" may become necessary.
  At least, have different library directories for different version
  of ocaml, ideally some scheme a la OSX to install several versions
  of the same package in parallel.

I personally don't think that standardizing the tools to produce
individual package is a useful move. Providing good tools to ease
package construction matters, but enforcing them on developpers is
counter-productive.  What is needed is just the glue to make it
uniform from the user point of view. Ocamlfind can probably
help there for complex cases, but as simple cases work well enough
with ocamlc, I would prefer it to stay optional for end-users (this is
certainly OK to rely on it in the implementation of the system).

One last comment on Windows. Since most development is taking place on
Unix, I think this is reasonnable to make the presence of basic cygwin
tools a requirement for compiling packages. The presence of gnu make
and some shell commands should be enough for most. Handling of C
libraries is more complex, but this must often be handled also at the
source level.

Thanks for reading my personal opinions.

Jacques Garrigue
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Fri, Feb 28, 2003 at 06:20:16PM +0900, Jacques Garrigue wrote:
>   
> * Easy installation means that you should be able to download, compile
>   and install the desired ocaml program or library in one single
>   command, including all the dependencies.
>   This does not mean that a binary should be available. A binary will
>   only work with a single version of ocaml and all dependencies, which

Yes, but notice that this may also be true for the source version, which
sometimes need to be changed between sucessive ocaml versions. Also,
this does not take into account the fact that the libraries you may use
will change also from time to time.

I have been confronted with this problem quite a bit, and i think we
need to move to something where each library (and ocaml suite) can
advertize its compatibility version. Something akin to the sonames used
by C shared libraries.

I began this move for the ocaml debian package in december, by moving
the libdir to /usr/lib/ocaml/3.06, and have planes to have fully
parallel instalable ocaml packages by the time 3.07 and debian/sarge are
released.

The libdir is only one thing, but there are also the binaries to take
into acount, most important among them is ocamlrun. I would encourage a
move from ocamlrun to ocamlrun-<version> in the standard install, or at
least a configure option to add the version number to all binaries.

The aim of this is to be able to still keep bytecode executables around
which were compiled for older versions, even when you are working with
the new version.

>   is way too restrictive. Binaries may be provided on a by OS basis,
>   but then it is much more comfortable for users to use the packaging
>   system provided by the OS (tgz on FreeBSD, rpms on redhat, deb on
>   debian, pkg on OSX, ??? on windows...) If the basic framework is
>   right, that work should be easy enough.

You know that there are at least 3 BSD ports of debian, not yet
official though. There is also work on debian/mingw, and debian/djpp
(for plain dos).

> * Dependency resolution and automatic recompilation/reinstallation is
>   the core of the problem.
>   When you modify an ocaml library, all its dependencies have to be
>   recompiled. You certainly want to automate this, and have some
>   foolproof system to be able to go back to a stable state. This is
>   also an area where a bit of compiler "support" may become necessary.
>   At least, have different library directories for different version
>   of ocaml, ideally some scheme a la OSX to install several versions
>   of the same package in parallel.

Yes, i agree with you on that.

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

Re: [Caml-list] Alternative proposal: COAN

[Jean-Christophe Filliatre]

 > I personally don't think that standardizing the tools to produce
 > individual package is a useful move. Providing good tools to ease
 > package construction matters, but enforcing them on developpers is
 > counter-productive. 

I strongly agree on this point too. 

As far as I'm concerned, I (try to) carefully package my libraries and
applications  so that  they  compile with  "./configure  && make"  and
install  with  "make  install".  (Libraries  are  installed  in  ocaml
standard  library  place, which  is  determined  automatically by  the
configure script; presence of a  native code compiler is also detected
automatically; etc.)

OcamlMakefile or findlib are surely great tools, but I can't see why I
should use them to contribute to a COAN.

I find the concept of a COAN really nice, by the way; I think Jacques'
idea  of a  central repository  with  meta informations  is the  right
compromise  between  the  current  situation  (humps)  and  the  heavy
solution of a centralized sources repository.

-- 
Jean-Christophe Filliâtre (http://www.lri.fr/~filliatr)

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

Re: [Caml-list] Alternative proposal: COAN

[Markus Mottl]

On Fri, 28 Feb 2003, Jean-Christophe Filliatre wrote:
> As far as I'm concerned, I (try to) carefully package my libraries and
> applications  so that  they  compile with  "./configure  && make"  and
> install  with  "make  install".  (Libraries  are  installed  in  ocaml
> standard  library  place, which  is  determined  automatically by  the
> configure script; presence of a  native code compiler is also detected
> automatically; etc.)

This is definitely a reasonable way to do it: "./configure && make &&
make install" is more or less the standard way of configuring, building
and installing software from source on Unix-systems, even if there are
plenty of developers who don't adhere to this quasi-standard.

> OcamlMakefile or findlib are surely great tools, but I can't see why
> I should use them to contribute to a COAN.

OCamlMakefile was never written with the intention to provide a
standard way of configuring, building and installing software. It
was designed to make things as easy as possible for OCaml-developers
of medium-sized projects and not too difficult for users in case the
developer wanted to ship OCamlMakefile for installation purposes. I'd
also prefer seeing cleaner and more portable solutions to the problem
of packaging OCaml-software.

> I find the concept of a COAN really nice, by the way; I think Jacques'
> idea  of a  central repository  with  meta informations  is the  right
> compromise  between  the  current  situation  (humps)  and  the  heavy
> solution of a centralized sources repository.

Jacques' idea also seems interesting to me. I brought up the topic
of having a standard for packaging OCaml-software in the past,
but unfortunately it obviously never made it on the agenda of the
INRIA-team. With a fast-growing user base, we really very badly need a
standard way of packaging, which should be "blessed" by INRIA. This would
give a tremendous boost to collaborative efforts in the community! But,
sigh, I understand that such a standard, possibly supported by tools,
is not a very sexy research topic...

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Fri, Feb 28, 2003 at 02:08:07PM +0100, Markus Mottl wrote:
> On Fri, 28 Feb 2003, Jean-Christophe Filliatre wrote:
> > As far as I'm concerned, I (try to) carefully package my libraries and
> > applications  so that  they  compile with  "./configure  && make"  and
> > install  with  "make  install".  (Libraries  are  installed  in  ocaml
> > standard  library  place, which  is  determined  automatically by  the
> > configure script; presence of a  native code compiler is also detected
> > automatically; etc.)
> 
> This is definitely a reasonable way to do it: "./configure && make &&
> make install" is more or less the standard way of configuring, building
> and installing software from source on Unix-systems, even if there are
> plenty of developers who don't adhere to this quasi-standard.

Yes, ...

I know i am repeating myself, but please consider adding the following
points also :

  o support the DESTDIR prefix to your install directory. distribution
    need to install into different directories than the ones the
    package will unpack into.

  o support separate compilation for bytecode and nativecode. I build
    bytecode versions of my packages on my i386 box alongside the native
    versions. The bytecode package is arch: all, and will be
    installeable on every arch, including slower arches like m68k, where
    building huge ocaml bytecode executables is a waste of time if it
    can be done quicker on my box.

This are the two parts most people don't ever think about, and for which
i need to patch the makefiles myself every time. I could double or
triple the amount of stuff i package if this was easier handled.

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

Re: [Caml-list] Alternative proposal: COAN

[Jean-Christophe Filliatre]

 > I know i am repeating myself, but please consider adding the following
 > points also :

Sorry, I forgot to comment on these points :

 >   o support the DESTDIR prefix to your install directory. distribution
 >     need to install into different directories than the ones the
 >     package will unpack into.

A  ./configure script  accepts a  --prefix option,  or  more precisely
--libdir, --bindir,  etc, setting some  variables at the  beginning of
the generated Makefile. Additionally,  it sets other variables such as
OCAMLLIB for  the ocaml standard  library place, etc.  Overiding these
variables when  compiling is possible  (make OCAMLLIB=... LIBDIR=...),
and thus using DESTDIR does not need changing the Makefile at all.

 >   o support separate compilation for bytecode and nativecode. I build
 >     bytecode versions of my packages on my i386 box alongside the native
 >     versions. The bytecode package is arch: all, and will be
 >     installeable on every arch, including slower arches like m68k, where
 >     building huge ocaml bytecode executables is a waste of time if it
 >     can be done quicker on my box.

The configure.in  / Makefile.in I provide  on my web  page also tackle
this  issue. The  makefile actually  contains two  targets  "byte" and
"opt"  for  bytecode  and  nativecode compilation.  The  "./configure"
script   determines  automatically   if   nativecode  compilation   is
supported, so that  "make" is doing the best  it can (always bytecode,
and nativecode when available). But  "make byte" and "make opt" can be
invoked  specifically, to  do one  particular  compilation. Similarly,
"make install-byte" or "make install-opt" can be invoked specifically.

-- 
Jean-Christophe Filliâtre (http://www.lri.fr/~filliatr)

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Fri, Feb 28, 2003 at 03:05:33PM +0100, Jean-Christophe Filliatre wrote:
> 
>  > I know i am repeating myself, but please consider adding the following
>  > points also :
> 
> Sorry, I forgot to comment on these points :
> 
>  >   o support the DESTDIR prefix to your install directory. distribution
>  >     need to install into different directories than the ones the
>  >     package will unpack into.
> 
> A  ./configure script  accepts a  --prefix option,  or  more precisely
> --libdir, --bindir,  etc, setting some  variables at the  beginning of
> the generated Makefile. Additionally,  it sets other variables such as
> OCAMLLIB for  the ocaml standard  library place, etc.  Overiding these
> variables when  compiling is possible  (make OCAMLLIB=... LIBDIR=...),
> and thus using DESTDIR does not need changing the Makefile at all.

Well, sure, that is ok if you use autoconf, but ./configure can be any
manner of selfmade shell script or whatever. Also many people prefere to
have a configure target in the makefile, which is ok with me.

And it is in these cases that DESTDIR need to be supported. Also the
point of it is to have a DESTDIR which you can change in the make
install, and which is different from the one you configure to.

>  >   o support separate compilation for bytecode and nativecode. I build
>  >     bytecode versions of my packages on my i386 box alongside the native
>  >     versions. The bytecode package is arch: all, and will be
>  >     installeable on every arch, including slower arches like m68k, where
>  >     building huge ocaml bytecode executables is a waste of time if it
>  >     can be done quicker on my box.
> 
> The configure.in  / Makefile.in I provide  on my web  page also tackle

Will have a look.

> this  issue. The  makefile actually  contains two  targets  "byte" and
> "opt"  for  bytecode  and  nativecode compilation.  The  "./configure"
> script   determines  automatically   if   nativecode  compilation   is
> supported, so that  "make" is doing the best  it can (always bytecode,
> and nativecode when available). But  "make byte" and "make opt" can be
> invoked  specifically, to  do one  particular  compilation. Similarly,
> "make install-byte" or "make install-opt" can be invoked specifically.

BTW, does make install-byte and make-install-opt install to the same
bynary name ?

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

Re: [Caml-list] Alternative proposal: COAN

[Benjamin C. Pierce]

Seems like maybe the beginnings of a minimalist proposal are beginning to
emerge from the discussion...

   - Using a "hump" model -- centrally stored meta-data pointing to
     actual package contents stored on people's individual servers and
     updated at will -- avoids uploading/mirroring issues.

     In fact, the current hump seems almost right -- it just needs
        - to be minimally machine readable (perhaps just able to export
          its DB in some simple XML format)
        - to have some way of indicating dependencies
        - to include pointers directly to package contents (not to
          people's web pages where packages can be found, etc.)

     For a notation for signalling dependencies, a little work is needed.
     But I have the impression that there are a number of people in the
     community that understand the issues rather well, and that a pretty
     simple solution would be good enough for 99.9% of the cases...

     For pointers to package contents, one should establish a common file
     naming convention -- e.g., record the URL of the package contents in
     the COAN as

         http://hostname.fr/path/mynicepackage-VERSION.tar.gz

     and store versions 1.2, 1.3, 1.5 on the server as

         http://hostname.fr/path/mynicepackage-1.2.tar.gz
         http://hostname.fr/path/mynicepackage-1.3.tar.gz
         http://hostname.fr/path/mynicepackage-1.5.tar.gz

   - Let people write their makefiles in whatever way they like, use
     findlib or not as they prefer, etc., but establish a minimal set
     of common requirements -- e.g. 
         - saying just 'make install' should do configuration if
           necessary, build bytecode and (if possible) native versions,
           and put them where they belong 
         - DESTDIR should be treated appropriately
         - etc.

     Again, there are several people in the community that have, among
     them, a pretty clear sense of what these minimal requirements should
     look like.  (I know there is some disagreement about details, but as
     a developer I don't really care -- I just want someone to decide on
     something reasonable and publish a template that I can follow if I
     want to contribute my code to the community.)  I'd love it if three
     or four of them could just get together, decide something
     reasonable, discuss it with the OCaml authors to make sure they
     agree, and tell the rest of us what to do.

I nominate Marcus, Jean-Christophe, Gerd, and Sven.  :-)

    -- Benjamin


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

Re: [Caml-list] Alternative proposal: COAN

[Blair Zajac]

Jacques Garrigue wrote:
> 
> * For me the central repository should not contain the source themselves.
>   This was an error with the CDK: the distribution becomes huge, and
>   it is very difficult for the maintainers to track changes
>   by developpers (who do not necessarily want to work in that
>   repository, for evident practical reasons). Not speaking of
>   licensing problems.

I see two different points here.  One being the huge CDK distribution,
which could have been broken up into individual .tar.gz's to handle
dependency tracking.

This is distinct from the central repository not containing sources
themselves, which I disagree with for several reasons.

1) Authors moving, redesigning web sites, etc.  Each move or redesign
   would have require module authors to go to the central repository
   to update links.  If the author has a lot of modules, this may be
   time consuming.

2) I think for security purposes, it would be good to have validated,
   md5sum'ed and potentially signed sources on a central site.  I
   would worry if I just automatically download some package from
   somebody's own web site.  I'm trusting the security on everybody's
   system, not just one.

3) Archive of old versions.  Authors may delete or clean up their own
   older versions of modules.  The central repository could keep all
   old copies which may be useful for some people.

As a CPAN author, when I put a package up on CPAN, I don't have to
worry about it any more.  That's a nice feeling to have.  I've moved
my web site 3 times in the last several years and updating links in a
repository would have been additional unnecessary work.

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
-------------------
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

Re: [Caml-list] Alternative proposal: COAN

[Michal Moskal]

On Fri, Feb 28, 2003 at 03:05:33PM +0100, Jean-Christophe Filliatre wrote:
> 
>  > I know i am repeating myself, but please consider adding the following
>  > points also :
> 
> Sorry, I forgot to comment on these points :
> 
>  >   o support the DESTDIR prefix to your install directory. distribution
>  >     need to install into different directories than the ones the
>  >     package will unpack into.
> 
> A  ./configure script  accepts a  --prefix option,  or  more precisely
> --libdir, --bindir,  etc, setting some  variables at the  beginning of
> the generated Makefile. Additionally,  it sets other variables such as
> OCAMLLIB for  the ocaml standard  library place, etc.  Overiding these
> variables when  compiling is possible  (make OCAMLLIB=... LIBDIR=...),
> and thus using DESTDIR does not need changing the Makefile at all.

DESTDIR affects *only* where you install files. --prefix and such often
affect paths compiled into the binaries. Overriding makefile variables
often work, but sometimes it does not (for example when configuration
files containing paths are created upon make install). This is why
DESTDIR support is encouraged.

It's needed to build debs and rpms, and is hard to write, so by putting
it in your package you enlarge chances to get new users, when someone
packages it :-)

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

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

[Caml-list] Re: hierarchical modules

[Xavier Leroy]

> I meant to send this a long time ago, but I forgot.  These are three
> reasons, from least to most important, why I think the -pack feature
> implemented in ocaml 3.06 is not sufficient for hierarchical modules.
> 
> 1. Compiled-in module and file names used for backtrace and assert are
> not fully qualified when using -pack.  I have seen several ambiguous
> backtraces when I used the same module name in two container modules
> (i.e. used the same file name in two directories).
> 
> 2. A module can not be -packed into a container module of the same name.
> 
> 3. I want a separate interface file for the container module. [...]

I agree with point 3.  In addition to the reasons you gave, the .mli
for the container module would be the best place to put its
documentation (for the final user).  One way to implement point 3
would be to do in ocamlc -pack exactly what ocamlc -c does: if there
is no .mli file, synthesize a .cmi interface; otherwise, check
compatibility with the .cmi interface derived from the .mli file.
I'll see if this can be implemented.

Point 2 doesn't seem too serious to me, since having the same name for
a module and one of its submodules is confusing to the final users
(e.g. Module.Module.value).

> I prefer specifying the container module name on the command line or
> adding a "package" declaration to the source file as in Java.

Well, that would be necessary to address your point 1, and would also
remove the dependency on the GNU binutils tools (for ocamlopt -pack).
The one drawback of this approach is that compiled files thus
"pre-packed" could not be linked or loaded in the toplevel, only the
packed container would be; that might make testing a bit harder.

- Xavier Leroy
-------------------
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

Re: [Caml-list] Re: hierarchical modules

[Michal Moskal]

On Sat, Mar 01, 2003 at 07:09:14PM +0100, Xavier Leroy wrote:
> > I prefer specifying the container module name on the command line or
> > adding a "package" declaration to the source file as in Java.
> 
> Well, that would be necessary to address your point 1, and would also
> remove the dependency on the GNU binutils tools (for ocamlopt -pack).
> The one drawback of this approach is that compiled files thus
> "pre-packed" could not be linked or loaded in the toplevel, only the
> packed container would be; that might make testing a bit harder.

IMHO not linking all modules packed with -pack when only one of them is
referenced is much more important. At least until we'll have shared
libraries.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

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

Re: [Caml-list] Re: hierarchical modules

[Xavier Leroy]

> IMHO not linking all modules packed with -pack when only one of them is
> referenced is much more important.

Probably, but that's orthogonal to the points that John Carr mentioned.
It looks feasible (but hard!) with native-code packed libraries, and
even harder with bytecode.  It's not often the case that a feature is
harder to implement in bytecode than in native code!  (The reason here
is that native-code compilations have these .cmx cross-module
optimization information that can be used to inform the client of a
packed module of the actual structure of the packing; while no such
info is available for clients compiled to bytecode.)

This needs more thinking...

- Xavier Leroy

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

Re: [Caml-list] Alternative proposal: COAN

[Xavier Leroy]

> [Package management in OCaml]

I'm catching up on this interesting discussion, and find myself in
violent agreement with Jacques: something like the BSD "ports" system,
concentrating on (re-)compilation from sources and dependency
management, sounds like a strong starting point.  

I tried to read the BSD "ports" manual once, and my head exploded
midway :-)  I hope we can simplify things a bit, though.

> * For me the central repository should not contain the source themselves.

I agree it should be sufficient to give a URL to the sources in the
metadata describing the package.  In some cases, library authors
cannot provide a really stable URL, hence some kind of mirrorring of
the sources might be necessary.  (And is a real nightmare to do: INRIA
can easily provide lots of disk space and bandwith, but making sure
that no-one uses the INRIA mirror to trade warez is the hard part :-)
But, yes, let's desing the system around the idea that sources are to
be downloaded from arbitrary URLs, like BSD ports do.

> * Dependency resolution and automatic recompilation/reinstallation is
>   the core of the problem.

Agreed.  What do you envision for this?  Is it enough for each package
to list the names and version number ranges for all the packages it
needs?  Or shall we try to exploit additionally the dependency
information (MD5 checksums of imported modules) already present in
compiled OCaml files?  

> I personally don't think that standardizing the tools to produce
> individual package is a useful move.

It's not necessary, but could help.  For the packaging tools to work,
each port will have to contain a makefile or shell script that
implements correctly a basic, shared protocol, e.g. "configure,
compile, and install yourself", or "uninstall yourself".  Providing
template makefiles that implement this protocol could help library
authors do the packaging.  

Also, as Nikolaj pointed out, precious few OCaml libraries build on
Windows.  That's basically because most library authors don't know
anything beyond Unix.  Again, template makefiles could help overcome
this issue.

Speaking of this, I've been considering generating a Makefile.inc file
as part of the OCaml installation, containing useful information such
as "where is the OCaml library?", "what version of OCaml is this?",
and "is the native code compiler supported?".  By just putting
        include `ocamlc -where`/Makefile.inc
in your makefiles, most of the need for an autoconfiguration script
could be avoided.

Finally, some standardization on where packages install their files
would help the end user.  Some packages install one module in the
OCaml stdlib dir, others install in a subdir of the stdlib, others
install in the "contrib" subdir, etc.  OCamlfind can handle all this,
but I believe more stringent guidelines on where libraries should go
would help.

> One last comment on Windows. Since most development is taking place on
> Unix, I think this is reasonnable to make the presence of basic cygwin
> tools a requirement for compiling packages. The presence of gnu make
> and some shell commands should be enough for most. Handling of C
> libraries is more complex, but this must often be handled also at the
> source level.

After years of struggling with nmake, I finally decided to rely on GNU
make and the Cygwin tools for building the windows versions of OCaml.
So, I agree that assuming Cygwin is present for building packages is a
reasonable thing to do.  Still, writing a makefile that works both
under Unix and Windows isn't trivial, due to stupid things like
different file extensions for C libraries (.a vs. .lib).  At least, I
haven't yet succeeded in having common makefiles for Unix and Windows
in the OCaml source tree.

- Xavier Leroy

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Sun, Mar 02, 2003 at 07:21:26PM +0100, Xavier Leroy wrote:
> > [Package management in OCaml]
> 
> I'm catching up on this interesting discussion, and find myself in
> violent agreement with Jacques: something like the BSD "ports" system,
> concentrating on (re-)compilation from sources and dependency
> management, sounds like a strong starting point.  
> 
> I tried to read the BSD "ports" manual once, and my head exploded
> midway :-)  I hope we can simplify things a bit, though.
> 
> > * For me the central repository should not contain the source themselves.
> 
> I agree it should be sufficient to give a URL to the sources in the
> metadata describing the package.  In some cases, library authors
> cannot provide a really stable URL, hence some kind of mirrorring of
> the sources might be necessary.  (And is a real nightmare to do: INRIA
> can easily provide lots of disk space and bandwith, but making sure
> that no-one uses the INRIA mirror to trade warez is the hard part :-)

Well, you only have to trust the people who will be uploading stuff. You
give each of them, either some kind of password, or you use an upload
queue or something such. You ask for the gpg/pgp key of the wouldbe
uploaders, and they send to an anonymous writable (but not readable)
directory the files they are uploading, together with some kind of
control file, containing a list of the uploaded files with their md5sum,
and maybe a small description of changes or whatever (and naturally the
package name). Then, a script is started from the cron table, looks the
upload directory for control files, if it finds one, checks it is
signed by someone you know, verify that the package he uploads is one
you have authorized, and verify the md5sum of the uploaded files. If all
this is ok, then the script just move the stuff to the download directory (in a
subdirectory corresponding to the package) and that is it. If all the
rest is ok, but the package is a new one, then you have a manual look at
it, and add it to the list of known packages. This can be done once a
week or whatever is best.

This is how the debian archives are managed, and it has worked well.
Sure, we have the added security that we don't allow anyone to enter the
keyring without having personnaly met another debian developper already
in the web of trust and that is identity has been acertained, but i
believe this is not really an issue here, and that you may also try to
meet other ocaml writing authors at conferences and other such, and thus
have a chance of adding them to your keyring.

> But, yes, let's desing the system around the idea that sources are to
> be downloaded from arbitrary URLs, like BSD ports do.
> 
> > * Dependency resolution and automatic recompilation/reinstallation is
> >   the core of the problem.
> 
> Agreed.  What do you envision for this?  Is it enough for each package
> to list the names and version number ranges for all the packages it
> needs?  Or shall we try to exploit additionally the dependency
> information (MD5 checksums of imported modules) already present in
> compiled OCaml files?  

I don't really like the idea of the range of version numbers. There is
no way you can know when a package will change in the future, and then
there is the issue of the version of ocaml it was built for (err, you
are speaking sources, so this is not as important, but still, there may
be source changes as well).

Anyway, i would much prefer that we begin to look at a formal versioning
system, for example a 3 level version system, where the first will be
for api changes, the second for backward compatible api changes (adding
stuff and the like), and the last will be for bug fixes and other non
api changing changes. This is something that is used for C so numbers,
and could work out well here. Basically it guarantees that if the api
number of a dependency did not change, then you can use it.

Sure, it needs more cooperation between the different module authors,
but i think that this will be accepted by them.

Also, this is for ocaml only, problems may happen with stublibs and
other non ocaml stuff, but in these cases, mostly libraries, i believe
depending on the right level of so number would be enough.

As for the build system, i will say here what i already told the small
group apointed by benjamin, i think it would be nice if we could just
have some kind of wrapper for the most common
configuration/build/installation options, and then have each package
provide a small ocaml module which would comply with the following
module type :

module type Ocaml_Package = sig
  val configure : ... -> string
  val build : ... -> string
  val install : ... -> string
end

where the ... would be replaced with the common option strings.

I think it can be expanded with some kind of listing of additional
option by the packages, and can then be used to build a simple little
installation program, or even dynamically loaded or something such.

This would solve all the request for simple and standard installation
processes, let yet the authors free to use whatever build system they
choose, provided they provide the appropriate wrapper, which would
server as documentation as well.

> > I personally don't think that standardizing the tools to produce
> > individual package is a useful move.
> 
> It's not necessary, but could help.  For the packaging tools to work,
> each port will have to contain a makefile or shell script that
> implements correctly a basic, shared protocol, e.g. "configure,
> compile, and install yourself", or "uninstall yourself".  Providing
> template makefiles that implement this protocol could help library
> authors do the packaging.  

See my above proposal.

> Also, as Nikolaj pointed out, precious few OCaml libraries build on
> Windows.  That's basically because most library authors don't know
> anything beyond Unix.  Again, template makefiles could help overcome
> this issue.

Well, maybe also because most libraries are bindings, which bind to
things not available on Windows, or because the windows install stuff is
much to complex. I had very little luck in making lablgtk work on
windows, it didn't find the right path and so on, very bothersom.

> Speaking of this, I've been considering generating a Makefile.inc file
> as part of the OCaml installation, containing useful information such
> as "where is the OCaml library?", "what version of OCaml is this?",
> and "is the native code compiler supported?".  By just putting
>         include `ocamlc -where`/Makefile.inc
> in your makefiles, most of the need for an autoconfiguration script
> could be avoided.
> 
> Finally, some standardization on where packages install their files
> would help the end user.  Some packages install one module in the
> OCaml stdlib dir, others install in a subdir of the stdlib, others
> install in the "contrib" subdir, etc.  OCamlfind can handle all this,
> but I believe more stringent guidelines on where libraries should go
> would help.

I thought the decision was to install into a subdir of the libdir, and
that the libdir was reserved for ocaml itself ? Did we not agree on that
a year or two ago ?

> > One last comment on Windows. Since most development is taking place on
> > Unix, I think this is reasonnable to make the presence of basic cygwin
> > tools a requirement for compiling packages. The presence of gnu make
> > and some shell commands should be enough for most. Handling of C
> > libraries is more complex, but this must often be handled also at the
> > source level.
> 
> After years of struggling with nmake, I finally decided to rely on GNU
> make and the Cygwin tools for building the windows versions of OCaml.
> So, I agree that assuming Cygwin is present for building packages is a
> reasonable thing to do.  Still, writing a makefile that works both
> under Unix and Windows isn't trivial, due to stupid things like
> different file extensions for C libraries (.a vs. .lib).  At least, I
> haven't yet succeeded in having common makefiles for Unix and Windows
> in the OCaml source tree.

I believe the wya to do is cross compile on a linux system. So nobody
would claim they are not familiar enough with windows and everyone would
have libraries installeable straight from unix sources. I have not done
this personnally, so maybe it is not all that simple, but maybe a
tutorial example of such a build system with one of the simpler
libraries (maybe camlzip) could be nice to have. If i had time, i would
investigate it. We have this under debian :

Description: Minimalist GNU win32 (cross) compiler
 A Linux hosted, win32 target, cross compiler for C/C++
 .
 Freedom through obsolescence.  Those who still really need to
 can now build windows executables from the comfort of Debian.
 .
 This package contains the C and C++ cross compilers.

I don't know if this would be enough to build at least part of ocaml,
and also don't know if it is feasible to use it to build a cross ocaml
compiler, but this would be a neat thing to do. If i had time for it i
would look into this.

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

Re: [Caml-list] Alternative proposal: COAN

[Doug Bagley]

Xavier Leroy <xavier.leroy@inria.fr> writes:
>> [Package management in OCaml]

>> * For me the central repository should not contain the source themselves.
>
> I agree it should be sufficient to give a URL to the sources in the
> metadata describing the package.  In some cases, library authors
> cannot provide a really stable URL, hence some kind of mirrorring of
> the sources might be necessary.  (And is a real nightmare to do: INRIA
> can easily provide lots of disk space and bandwith, but making sure
> that no-one uses the INRIA mirror to trade warez is the hard part :-)
> But, yes, let's desing the system around the idea that sources are to
> be downloaded from arbitrary URLs, like BSD ports do.

Personally, I think it is much better to have the sources uploaded to
a central repository.

A couple times I have gone to the Hump, and the link for a package no
longer exists. If that author had uploaded to a centralized server,
the package is not subject to "link rot". I think this kind of problem
becomes much more frustrating for the user when dependencies become
involved, and one of the prerequsites needed by the package you really
want to install has gone missing. A centralized archive is also a boon
to those who do not have easy access to a stable server that can host
their package.

For some time now, I have been thinking about how nice a "COAN" for
Ocaml would be ... I would like to help out.

Cheers,
Doug

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

Re: [Caml-list] Alternative proposal: COAN

[Nicolas Cannasse]

> One last comment on Windows. Since most development is taking place on
> Unix, I think this is reasonnable to make the presence of basic cygwin
> tools a requirement for compiling packages. The presence of gnu make
> and some shell commands should be enough for most. Handling of C
> libraries is more complex, but this must often be handled also at the
> source level.

The need of having cygwin installed if you're not using the cygwin ocaml
version is quite a problem. I totally agree with you when you say that OCaml
binary distributions are not suitable (right now - maybe later). But that
goes for the Caml part of the package, and not really for the C stubs.
As a windows Ocaml user, I would strongly recommend that the package authors
who wants to support the Win32 target do the following :
- if the package only contains Caml code, release a full source code
- if the package contains both Caml and C stubs :
    * release the full source code using gnu/shell tools for compiling (for
unix users and windows users who are familiar with such tools)
    * release a half-binary Windows code where the C compiled dll/lib are
provided with the full Caml source code only ( a separate tool like ocamake
can handle the compilation )

For all things concerning installation, I think it's far more easy on
windows than on unix systems, and so should be handled separatly (a caml
written tool not relying on cygwin shell tools should be enough, according
that the package author provide a minimum information on
how-to-install-it ).

PS : I'm a cygwin gnu/shell tools user, but I personnaly think that most of
windows developpers are not willing to do so, and that providing tools for
it is more in the windows-way-of-thinking.

Waiting for comments,

Nicolas Cannasse

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Mon, Mar 03, 2003 at 11:39:36AM +0900, Nicolas Cannasse wrote:
> > One last comment on Windows. Since most development is taking place on
> > Unix, I think this is reasonnable to make the presence of basic cygwin
> > tools a requirement for compiling packages. The presence of gnu make
> > and some shell commands should be enough for most. Handling of C
> > libraries is more complex, but this must often be handled also at the
> > source level.
> 
> The need of having cygwin installed if you're not using the cygwin ocaml
> version is quite a problem. I totally agree with you when you say that OCaml
> binary distributions are not suitable (right now - maybe later). But that
> goes for the Caml part of the package, and not really for the C stubs.
> As a windows Ocaml user, I would strongly recommend that the package authors
> who wants to support the Win32 target do the following :
> - if the package only contains Caml code, release a full source code
> - if the package contains both Caml and C stubs :
>     * release the full source code using gnu/shell tools for compiling (for
> unix users and windows users who are familiar with such tools)
>     * release a half-binary Windows code where the C compiled dll/lib are
> provided with the full Caml source code only ( a separate tool like ocamake
> can handle the compilation )
> 
> For all things concerning installation, I think it's far more easy on
> windows than on unix systems, and so should be handled separatly (a caml
> written tool not relying on cygwin shell tools should be enough, according
> that the package author provide a minimum information on
> how-to-install-it ).

Well, like said, i never managed to got thing to install/compil properly
on windows (sure, i was trying to build a windows advi, which is not
possible, but still). The biggest help the windows users can do
themselves, is that some of you write an howto on how to do ocaml
developpment on windows, and describe it so that people can give it a
try, without the headache of trying to figure out how it is supposed to
work, and why it is not working, and other such. I myself did give it a
try from time to time, but after the headache that this involves, i just
thought to hell with it, it is not worth the time spent, and abandoned
the whole idea. I guess many other unix developpers think the same, and
windows will be going away anyway in a few years, so ... :))))

> PS : I'm a cygwin gnu/shell tools user, but I personnaly think that most of
> windows developpers are not willing to do so, and that providing tools for
> it is more in the windows-way-of-thinking.

Like said, fine with me, but i guess the windows way of thinking is that
it should work out of the box and without many problems. BTW, how do you
do Makefiles with the visual C++ developpment tools ?

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

Re: [Caml-list] Alternative proposal: COAN

[Nicolas Cannasse]

> Like said, fine with me, but i guess the windows way of thinking is that
> it should work out of the box and without many problems. BTW, how do you
> do Makefiles with the visual C++ developpment tools ?

You can create a "Makefile project" from within the project wizard or use
the VisualML Project Wizard I wrote to setup a new project. As you can run
any command ( nmake or other ) you only have to call ocamake passing it the
vc++ DSP project file as argument. Ocamake will get the file list from it.

More infos here : http://tech.motion-twin.com

Nicolas Cannasse

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

Re: [Caml-list] Alternative proposal: COAN

[Sven Luther]

On Mon, Mar 03, 2003 at 06:24:48PM +0900, Nicolas Cannasse wrote:
> > Like said, fine with me, but i guess the windows way of thinking is that
> > it should work out of the box and without many problems. BTW, how do you
> > do Makefiles with the visual C++ developpment tools ?
> 
> You can create a "Makefile project" from within the project wizard or use
> the VisualML Project Wizard I wrote to setup a new project. As you can run
> any command ( nmake or other ) you only have to call ocamake passing it the
> vc++ DSP project file as argument. Ocamake will get the file list from it.

Ok, now, if i have an existing ocaml library/program/whatever which
knowns nothing about VC++, you only need to generate the CV++ DSP
project, right ? Or are there some more evoluted steps do it ?

Also, if i have an lablgtk interface, there is no chance i can use it
with VC++ and the standard windows runtime ?

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

Re: [Caml-list] Alternative proposal: COAN

[Jeff Bowden]

>
>
>      But, wait, after all, this is pretty similar to what is done by apt in the Debian
>      linux distribution! Probably one should have a look at apt as a starting
>      point. I would be interested to have the feelings of the various
>      people here that do Debian packages on the suitability of the apt tools to
>      handle this kind of issues in the Ocaml world.
>  
>


This may be of interest: http://www.cliki.net/cclan
-------------------
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