On Jan 29, 2008 5:56 AM, Berke Durak <berke.durak@exalead.com> wrote:
Basing a PMS for Ocaml on a VCS written in Haskell would violate the
``Trading with the Enemy'' act.  Moreover Darcs has some performance
problems of its own.

Come now, Haskell is a dear friend and relative, not an enemy at all.

Besides, darcs has some key advantages for this kind of use.  Cherry-picking and flexible maintenance of patches on top of someone else's tree would be very valuable for this kind of application, and neither hg nor git support that use case well.  And I believe the darcs team is making real advances towards fixing these problems.

If not darcs, I would choose hg next.  hg supports windows well, which is a big deal, I think.  Its user interface was more pleasant than git's last I checked.  And it has some support for renames (not as good as darc's or bzr's, but still good.)  We've used hg very intensively at Jane Street and have been very happy with the results. 
 
Let's get back to the subject.  BSD ports are also based on make,
whose main limitation, the static dependency graph, has been addressed
in ocamlbuild.  I know there is Omake, but I think it suffers from the
``Yet Another Turing-Complete Language'' syndrome.

Does anyone with experience with both omake and ocamlbuild have an opinion on the matter?  I've used omake quite a bit, and ocamlbuild not at all.   In my mind, omake has the advantage that I'm pretty sure it's up to the task.  ocamlbuild has the advantage of being in the standard distribution and having OCaml as its extension language.  It would be great to get the opinion of someone who knows both systems well. 
 
So I am calling for a solution based on a ports-like system but based
on a distributed VCS and on an improved ocamlbuild.

Assume you are writing a program FOO and want to use a package BAR
available from bar.org.  You tell ocamlbuild by adding some tag such
as

  <mytarget.native>: require(http://bar.org/repository/)

It would also be nice to have a set of versions of the various libraries that hang together, as GODI does.  Otherwise, problems in the case where there are packages A, B and C where A depends on B and C and B depends on C.  You need a version of C that works with your versions of A and B, or you're sunk.  So some central repo where you can maintain a set of "safe" versions would allow for a developer to ask for a easily pull a collection of working libraries.
 
y