what's in the future for ocamlbuild?

* what's in the future for ocamlbuild?
@ 2008-03-12  4:57 Erick Tryzelaar
  2008-03-12  9:14 ` [Caml-list] " David Allsopp
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Erick Tryzelaar @ 2008-03-12  4:57 UTC (permalink / raw)
  To: caml-list

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 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.

- 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:

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.

There's more I could add, but I hope this can start a conversation
about this. What do the rest of you think?

^ permalink raw reply	[flat|nested] 14+ messages in thread