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 (09:15)
From: David Allsopp <dra-news@m...>
Subject: RE: [Caml-list] what's in the future for ocamlbuild?
Having only just made the shift to OCaml 3.10, I haven't tried using
ocamlbuild yet for anything of my own so I'm interested in the
incompatibility with Windows listed below.

When you say that it doesn't work with cmd.exe, do you mean that bash simply
needs to be in the PATH so that ocamlbuild can execute commands? The Win32
port of make has the same requirement for sh.exe - I can't see how that's a
show-stopper for OCaml on Windows?

For my build (MinGW+Cygwin) I don't have Cygwin's bin folder in %PATH%
(because it interferes with the native Win32 ports of the UNIX commands) but
have C:\Dev\OCaml\bin instead. In that folder, apart from all OCaml's
binaries, I place copies of Cygwin's gcc.exe, as.exe, ar.exe, ranlib.exe and
dlltool.exe (with Cygwin DLLs copied to system32) to allow ocamlopt to work.
I'd see no problem with adding bash.exe to allow ocamlbuild to work too.

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


-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Erick Tryzelaar
Sent: 12 March 2008 04:57
To: caml-list@inria.fr
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

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


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: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs