Excerpts from Erick Tryzelaar's message of Wed Mar 12 05:57:12 +0100 2008:
> After reading the ocamlbuild + findlib thread, it reminded me about
> some of the concerns I have with ocamlbuild. It's a really cool
> system, but there doesn't seem to be much public planning and
> contribution to making it better. For instance, it seems like the
> community is waiting for Nicolas Pouillard to add support for multiple
> plugins instead of us working together to spec out and create it
> ourselves.
> 
> Why is this? For me at least, I think some of it is that I see
> ocamlbuild being intimately tied in with inria's ocaml compiler, and
> inria has been reasonably quiet about future development and external
> participation. So, unlike other projects, I've never really put that
> much effort into submitting patches. Is there anything we can do to
> change this?
> 
> There are a couple things that I've long thought would be great to
> have in ocamlbuild:
> 
> - I love that ocamlbuild is bundled with ocaml as then it's one less
> dependency for someone building an ocaml package, but I don't like how
> it then ties it's release to ocaml releases. First, since new versions
> of ocaml aren't really publicly planned, it's hard to know when a
> feature might be added to ocamlbuild. Second, we can't use ocamlbuild
> to build a system if the system compiler isn't 3.10. I don't think
> ocamlbuild actually uses anything from 3.10. So, it would be nice if
> there was also a separate release from ocaml that we could install
> along side of an older ocaml install.

As in my previous mail, that's not planned to ship it apart.

> - Now, in order to use it along side an older install, you can't
> actually use a myocamlbuild.ml file as you'd have conflicting versions
> of libraries. So, beyond what you can do with just the current _tags
> file, it'd be also great if we could add support for some of the more
> common features you need to go to myocamlbuild.ml right now. For
> instance, you have to declare a library through "ocaml_lib". Could we
> extend the _tags file support something like:
> 
> <foo.cma>: use_bar
> ocaml, library, byte, use_foo: foo.cma
> ocaml, library, byte, use_bar: bar.cma, external, dir('bar')
> 
> With this and other similar extensions, we wouldn't have to go to
> myocamlbuild as much. I don't think _tags should grow into a full
> language, but I think we could cover more common cases with it.

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.

> - A way for the community to add support for other languages. It may
> not make sense to code in the OCaml tree support for things like Java
> or the QT library. It also might not really be appropriate to be done
> through OSR either.

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.

> - ocamlbuild currently can't run on windows's cmd.exe, which is a
> shame. This bug report suggests that it's not planned on changing
> either:
> 
> http://caml.inria.fr/mantis/view.php?id=4388
> 
> I know that other languages like python are able to work cross
> platformly with cmd.exe (such as my custom python build system for
> felix), so for at least my purposes it works fine. In my case I'd be
> okay with accepting the limitations of cmd.exe by avoiding doing any
> fancy shell scripts, or pushing that in smart wrappers to ocamlbuild.
> Furthermore, you could just skip the shell altogether and either
> fork-exec on linux or runProcess on windows.

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

-- 
Nicolas Pouillard aka Ertai