Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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:10)
From: Nicolas Pouillard <nicolas.pouillard@g...>
Subject: RE: [Caml-list] what's in the future for ocamlbuild?
Excerpts from David Allsopp's message of Wed Mar 12 09:14:47 UTC 2008:


> AFAIK ocamlbuild uses the new camlp4 so, while not impossible, back-porting
> it to work with <= 3.09 is at best non-trivial?

No  ocamlbuild don't use camlp4. However camlp4 use ocamlbuild. And ocamlbuild
functions like Unix.isatty and Sys.is_directory. That appears in 3.10.

Moreover I don't have enough time to release/package ocamlbuild more often.

Hopefully  ocamlbuild plugins are a way to extend it and try new ideas without
waiting for a release.

> -----Original Message-----
> From:
> [] On Behalf Of Erick Tryzelaar
> Sent: 12 March 2008 04:57
> To:
> Subject: [Caml-list] what's in the future for ocamlbuild?
> 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.
> - Now, in order to use it along side an older install, you can't
> actually use a 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 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.
> - 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.
> - 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:
> 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.
> There's more I could add, but I hope this can start a conversation
> about this. What do the rest of you think?
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports:
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports:

Nicolas Pouillard aka Ertai