Browse thread
what's in the future for ocamlbuild?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2008-03-12 (17:06) |
From: | Erick Tryzelaar <idadesub@u...> |
Subject: | Re: [Caml-list] what's in the future for ocamlbuild? |
2008/3/12 Nicolas Pouillard <nicolas.pouillard@gmail.com>: > As in my previous mail, that's not planned to ship it apart. That's understandable, but too bad. Would changes in ocamlbuild be enough to justify a new release for ocaml even if the rest of ocaml doesn't change? Or would we have to wait for bug fix patches like for 3.10.1 and 3.10.2? Furthermore, since ocamlbuild is still pretty young, what if we as a community decided to make a backwards incompatible change to the api? Would that have to wait until 3.11 or later? > 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. I agree. I just wanted to throw the idea out there to express the desire that if ocamlbuild becomes a general purpose builder, it should be able to work in most situations without actually even having ocaml installed. > 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. Great. What was done and is it released already? This, then, starts to run into the same kind of issues that the OSR folks are trying to solve. How can we standardize future plugins so that they're easy to install and use by everyone? I'm worried that except for a couple small cases, most changes will need to be done with an external plugin in order to keep the ocaml tree free from clutter. For instance, a build farm could be made with ocamlnet, which you might not even be legally allowed to pull into ocaml and distribute under the Q License. > We really lacks some windows experts for ocamlbuild and OCaml in general. The > specific problem of cmd.exe vs bash only one of them. Certainly. But the ocamlbuild challenges might be easier to solve than for the rest of ocaml. If I put in the time to work around the cmd.exe/bash problem for ocamlbuild by exposing fork/exec or runProcess and possibly more to the unix library, would the ocaml team accept it? And even more, would I have to wait a couple months for 3.10.3 for all of my OSS projects that run on windows (and through cmd.exe fine right now) to use it?