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 (15:25)
From: Nicolas Pouillard <nicolas.pouillard@g...>
Subject: Re: [Caml-list] what's in the future for ocamlbuild?
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 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