From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 47D06BBC1 for ; Wed, 12 Mar 2008 16:25:42 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,488,1199660400"; d="asc'?scan'208";a="8309086" Received: from peray.inria.fr (HELO ausone.inria.fr) ([128.93.8.98]) by mail2-relais-roc.national.inria.fr with SMTP; 12 Mar 2008 16:25:42 +0100 Received: by ausone.inria.fr (sSMTP sendmail emulation); Wed, _d Mar 2008 16:24:29 +0100 From: "Nicolas Pouillard" Subject: Re: [Caml-list] what's in the future for ocamlbuild? To: Caml_mailing list References: <1ef034530803112157m3bb804f4w6723252a84c2ec62@mail.gmail.com> In-Reply-To: <1ef034530803112157m3bb804f4w6723252a84c2ec62@mail.gmail.com> Date: Wed, 12 Mar 2008 16:24:29 +0100 Message-Id: <1205334970-sup-7754@port-ext16.ensta.fr> User-Agent: Sup/git Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=-1205335469-265066-11757-8118-3-="; micalg="pgp-sha1" MIME-Version: 1.0 X-Spam: no; 0.00; findlib:01 inria's:01 ocaml:01 compiler:01 ocaml:01 compiler:01 lib:01 foo:01 byte:01 foo:01 byte:01 dependencies:01 mikkel:01 rgensen:01 bug:01 X-Attachments: cset="UTF-8" type="application/pgp-signature" name="signature.asc" name="signature.asc" --=-1205335469-265066-11757-8118-3-= Content-Type: text/plain; charset=UTF-8 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: > > : 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 --=-1205335469-265066-11757-8118-3-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfX9a0ACgkQj+FCNw9dwLl2+wCgh0kzPbNYPiYG4XwnWK3lYLz4 qnMAn2Kd9ULksuQ2129ZdM1Y2m7SkhQH =em5B -----END PGP SIGNATURE----- --=-1205335469-265066-11757-8118-3-=--