From: "Nicolas Pouillard" <nicolas.pouillard@gmail.com>
To: Caml_mailing list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] what's in the future for ocamlbuild?
Date: Wed, 12 Mar 2008 16:24:29 +0100 [thread overview]
Message-ID: <1205334970-sup-7754@port-ext16.ensta.fr> (raw)
In-Reply-To: <1ef034530803112157m3bb804f4w6723252a84c2ec62@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3955 bytes --]
Excerpts from Erick Tryzelaar's message of Wed Mar 12 05:57:12 +0100 2008:
> 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.
As in my previous mail, that's not planned to ship it apart.
> - 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.
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.
> - 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.
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.
> - 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.
We really lacks some windows experts for ocamlbuild and OCaml in general. The
specific problem of cmd.exe vs bash only one of them.
--
Nicolas Pouillard aka Ertai
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
next prev parent reply other threads:[~2008-03-12 15:25 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 ` Nicolas Pouillard [this message]
2008-03-12 17:06 ` [Caml-list] " Erick Tryzelaar
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=1205334970-sup-7754@port-ext16.ensta.fr \
--to=nicolas.pouillard@gmail.com \
--cc=caml-list@yquem.inria.fr \
/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