English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
what's in the future for ocamlbuild?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-03-12 (17:06)
From: Erick Tryzelaar <idadesub@u...>
Subject: Re: [Caml-list] what's in the future for ocamlbuild?
2008/3/12 Nicolas Pouillard <nicolas.pouillard@gmail.com>:
>  As in my previous mail, that's not planned to ship it apart.

That's understandable, but too bad. Would changes in ocamlbuild be
enough to justify a new release for ocaml even if the rest of ocaml
doesn't change? Or would we have to wait for bug fix patches like for
3.10.1 and 3.10.2? Furthermore, since ocamlbuild is still pretty
young, what if we as a community decided to make a backwards
incompatible change to the api? Would that have to wait until 3.11 or

>  The  _tags  file  is  for  tagging,  having  a way to specify dependencies and
>  libraries  would  be  cool,  but  I  want  to  avoid  the programming language
>  syndrome. It needs to be carefully designed.

I agree. I just wanted to throw the idea out there to express the
desire that if ocamlbuild becomes a general purpose builder, it should
be able to work in most situations without actually even having ocaml

>  It  would  be  very  nice. Mikkel Fahnøe Jørgensen already worked for a better
>  C/C++  integration.  However  this  also  requires  multiple plugins, since we
>  don't  want  to  integrate  all  these  languages  in  the  default  state  of
>  ocamlbuild.

Great. What was done and is it released already?

This, then, starts to run into the same kind of issues that the OSR
folks are trying to solve. How can we standardize future plugins so
that they're easy to install and use by everyone? I'm worried that
except for a couple small cases, most changes will need to be done
with an external plugin in order to keep the ocaml tree free from
clutter. For instance, a build farm could be made with ocamlnet, which
you might not even be legally allowed to pull into ocaml and
distribute under the Q License.

>  We  really lacks some windows experts for ocamlbuild and OCaml in general. The
>  specific problem of cmd.exe vs bash only one of them.

Certainly. But the ocamlbuild challenges might be easier to solve than
for the rest of ocaml. If I put in the time to work around the
cmd.exe/bash problem for ocamlbuild by exposing fork/exec or
runProcess and possibly more to the unix library, would the ocaml team
accept it? And even more, would I have to wait a couple months for
3.10.3 for all of my OSS projects that run on windows (and through
cmd.exe fine right now) to use it?