From: "Erick Tryzelaar" <idadesub@users.sourceforge.net>
To: "Nicolas Pouillard" <nicolas.pouillard@gmail.com>
Cc: "Caml_mailing list" <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] what's in the future for ocamlbuild?
Date: Wed, 12 Mar 2008 10:06:17 -0700 [thread overview]
Message-ID: <1ef034530803121006m6d2ec39fwb8bec1e8e7a94961@mail.gmail.com> (raw)
In-Reply-To: <1205334970-sup-7754@port-ext16.ensta.fr>
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?
prev parent reply other threads:[~2008-03-12 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-12 4:57 Erick Tryzelaar
2008-03-12 9:14 ` [Caml-list] " David Allsopp
2008-03-12 15:08 ` Nicolas Pouillard
2008-03-12 17:16 ` Erick Tryzelaar
2008-03-12 9:31 ` Sylvain Le Gall
2008-03-12 11:59 ` [Caml-list] " Lionel Elie Mamane
2008-03-12 12:05 ` Vincent Hanquez
2008-03-12 14:22 ` Sylvain Le Gall
2008-03-12 14:38 ` [Caml-list] " Vincent Hanquez
2008-03-12 14:52 ` Martin Jambon
2008-03-12 15:14 ` Sylvain Le Gall
2008-03-12 15:11 ` [Caml-list] " Nicolas Pouillard
2008-03-12 15:24 ` [Caml-list] " Nicolas Pouillard
2008-03-12 17:06 ` Erick Tryzelaar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ef034530803121006m6d2ec39fwb8bec1e8e7a94961@mail.gmail.com \
--to=idadesub@users.sourceforge.net \
--cc=caml-list@yquem.inria.fr \
--cc=nicolas.pouillard@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox