From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 59D2881799 for ; Thu, 25 Jul 2013 22:18:41 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of wojciech.meyer@gmail.com) identity=pra; client-ip=74.125.82.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of wojciech.meyer@gmail.com designates 74.125.82.44 as permitted sender) identity=mailfrom; client-ip=74.125.82.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f44.google.com) identity=helo; client-ip=74.125.82.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="postmaster@mail-wg0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjICABmH8VFKfVIsk2dsb2JhbABagztEq0OOOoNwgRcWDgEBAQEHCwsJFAQkgiQBAQEDAQEBAT0BGxILAQMMBgULDQkEDxIPAQQNAgQBDAEFAQoYExICBYdkAQMJBgQInAOMT4J/hD8KGScDCmSHdAEFDI0JGYEKgUUHhAADlRhegWmBKYp+g0E/hDs X-IPAS-Result: AjICABmH8VFKfVIsk2dsb2JhbABagztEq0OOOoNwgRcWDgEBAQEHCwsJFAQkgiQBAQEDAQEBAT0BGxILAQMMBgULDQkEDxIPAQQNAgQBDAEFAQoYExICBYdkAQMJBgQInAOMT4J/hD8KGScDCmSHdAEFDI0JGYEKgUUHhAADlRhegWmBKYp+g0E/hDs X-IronPort-AV: E=Sophos;i="4.89,745,1367964000"; d="scan'208";a="27343890" Received: from mail-wg0-f44.google.com ([74.125.82.44]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Jul 2013 22:18:40 +0200 Received: by mail-wg0-f44.google.com with SMTP id l18so2080371wgh.35 for ; Thu, 25 Jul 2013 13:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=B5NfbXjBMgMD+XMcpucEcZQAcEMiL/+imWvOO7F55wU=; b=0678eHvVqBfkJJ0n5Rq0gV1MyUmLwSLAQyBi/nVgW2w/LeTv/0jVsI5vXWy5LDts53 SHCdEhUu/qnhjH+kpaFfbn0Vk9X0TGX2M55jOml9hufNN6+Hy+Gfuk68/YLE5IW0FH52 CnQt9K2MJ4pO3Hhieg/im78IZf74LNvDKIViddK9KENUyJZX779CJ3nto0ka+MUaXEQl uvH2mDrHlArxwQwtgSPFskHZZryZeLc9sG5iZnTt9A9eYM2B2k+GSblzbt/u6b0zH9wa RlbufkxyKpZao9QuUSTzXazBMLmztjIv+TMerioDm34fgrBdaax6z9X4Tx9MFv91Oxeg mF2g== X-Received: by 10.194.108.73 with SMTP id hi9mr20989125wjb.85.1374783520289; Thu, 25 Jul 2013 13:18:40 -0700 (PDT) Received: from localhost.danmey.org (cpc2-cmbg12-0-0-cust796.5-4.cable.virginmedia.com. [86.9.203.29]) by mx.google.com with ESMTPSA id ev19sm291975wid.2.2013.07.25.13.18.38 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 13:18:39 -0700 (PDT) From: Wojciech Meyer To: Gabriel Scherer Cc: Anil Madhavapeddy , Markus Mottl , Thomas Gazagnaire , Gerd Stolpmann , Fabrice Le Fessant , Francois Berenger , Ocaml Mailing List References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> <7F8931D5-E65D-49EB-B54D-A50716F3EFDD@recoil.org> Date: Thu, 25 Jul 2013 21:18:30 +0100 In-Reply-To: Wojciech Meyer's message of "Wed\, 24 Jul 2013 18\:22\:20 +0100" Message-ID: <874nbis8a1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] GODI is shutting down I want to say, at any point, ocamlbuild will get fixes and improvements from the maintainers (mostly Gabriel Scherer and me), but we also look quite much for the community patches. Nothing makes our life easier than a good patch improving the tool or fixing some problem. This is a gentle encouragement for those who would like to contribute but somewhat think that will hit the wall of bureaucracy. We usually act quite fast if the patch submitted is well prepared. OCamlbuild has a huge potential, and will remain maintained. We are also thinking about larger developments, (improving performance, tighter ocamlfind integration, exposing the interface) but pretty much we would like to discuss it with the community, to ensure it's that what we want. Gabriel Scherer writes: >>> I think that's fair, but the devil is in the details. The core of OASIS >>> is sound, but is hampered by its need to build on top of ocamlfind >>> and ocamlbuild, and the ensuing impedance mismatches that follow (e.g. >>> manually editing _tags files, and trying to debug which tool a failure >>> happens in is an advanced operation). OPAM packages represent an output >>> collection of (several optionally built) ocamlfind packages, and >>> OASIS sits awkwardly in between these two right now, with ocamlbuild >>> crashing the party and getting drunk in the kitchen. >> >> While we're at it (and hoping a diversion might restores some >> constructiveness in this discussion), I have also been thinking about >> this aspect of OASIS that I don't really like. I use ocamlbuild >> -use-ocamlfind, but I'd rather build my _tags and myocamlbuild.ml >> files completely separately from OASIS, and avoid that intermixing of >> several tools. OASIS could decide which files to build (by calling >> whichever build system I use with those as targets) and include in the >> user installation, but I'd rather have full control of the build >> system independently. >> >> In fact, that's more or less what there is in Batteries; we use >> ocamlbuild, with a Makefile on top of it (to easily integrate some >> hacks such as inline tests using >> https://github.com/vincent-hugot/iTeML ), and use the XCustomBuild >> option of OASIS to tell it to use the makefile. This avoids having >> autogenerated stuff in the ocamlbuild setup, but currently OASIS has >> no say on which files to build (it gets what "make all" produces). >> >> In theory, integrating OASIS and the build system would allow OASIS to >> diffuse best practices at the build system level as well. In practice >> as a package developer I'm not fond on this combination, and I would >> rather let a QA pass do the kind of checks to avoid what a tight OASIS >> + build system integration would have made impossible in the first >> place (missing .cmt or what not). >> >> PS: ocamlbuild has been getting bugfixes and improvements relatively >> fast these last few months, in particular thanks to the completely >> benevolous efforts of Wojchiech Meyer. I'm confident it will continue >> to improve on the known-problematic fronts (terse documentation, >> unfriendly failure behaviours, disappointing parallelization, etc) in >> the future, which may help for some of your "fast Mirage" goals. >> >> On Wed, Jul 24, 2013 at 6:39 PM, Anil Madhavapeddy wrote: >>> On 24 Jul 2013, at 08:58, Markus Mottl wrote: >>> >>>> My guess is that you are not totally happy with Oasis at this point so >>>> this may be a topic to address. Being an Oasis user, I would say that >>>> the Oasis tools may not be as mature yet as one would hope, but the >>>> Cabal-like package specification syntax seems decent enough to be >>>> supported by OPAM. It really shouldn't be that hard to automate the >>>> process of updating OPAM metadata (including version constraints) >>>> based on changes in Oasis package specifications. >>> >>> I think that's fair, but the devil is in the details. The core of OASIS >>> is sound, but is hampered by its need to build on top of ocamlfind >>> and ocamlbuild, and the ensuing impedance mismatches that follow (e.g. >>> manually editing _tags files, and trying to debug which tool a failure >>> happens in is an advanced operation). OPAM packages represent an output >>> collection of (several optionally built) ocamlfind packages, and >>> OASIS sits awkwardly in between these two right now, with ocamlbuild >>> crashing the party and getting drunk in the kitchen. >>> >>> OASIS is structured very well to help get around this situation though. >>> It has a library that takes care of parsing the _oasis file, and then a >>> plugin generator that currently uses ocamlbuild to drive this specification >>> into concrete outputs. Meanwhile, the OCaml compiler has been exposing >>> more of its innards via compiler-libs. Leo and I are taking advantage of >>> this by trying to folding all of these layers into a new "packaging-friendly" >>> OCaml driver that statically links: >>> >>> - all the camlp4 libraries required for a project, and directly calls it >>> instead of going via -pp (avoiding a fork/marshal). >>> - links to OPAM/findlib to find dependencies directly, avoiding a shell >>> out to ocamlfind. >>> - can publish a static schedule of its activities to help Makefiles >>> figure out what actually got built (similar to the recent ocamlbuild >>> request). >>> >>> The idea is to have a "ocamlmkcompiler" that builds a binary for-purpose, >>> as "ocamlmktop" does today for toplevels. It shouldn't even need any >>> patches to the official compiler, thanks to compiler-libs. More to the >>> point, it should make it far easier to build a camlp4-aware js_of_ocaml >>> toplevel, to fit into the experiments that OCamlPro is doing with web >>> IDE interfaces. >>> >>> Anyway, these are still experiments and quite likely to run into unexpected >>> issues as we build them, and we'll have to consider all the alternatives >>> before folding them all into OPAM. >>> >>> Right now, OPAM dictates the *minimal* possible set of requirements for >>> a package since it just uses shell commands. It should be possible to >>> specialise this for common cases such as a OASIS library, but it does >>> require some careful thought first. Luckily, we can use OPAM itself to >>> conduct such experiments [1]. >>> >>> All such discussions and experiments are very welcome on the mailing >>> list (http://lists.ocaml.org/listinfo/opam-devel) to help establish >>> everyone's use cases. Daniel Buenzli's input has been particularly >>> interesting to date, as his libraries adopt a very minimal shell-script >>> driven approach that doesn't use OASIS, but still distributes META files. >>> That's just one example of someone that doesn't use OASIS directly. >>> The Core OASIS files are also a bit special due to their configuration >>> requirements. Xen/Mirage is also quite demanding in terms of the >>> compilation environment. >>> >>> Here's my goal: I want to have near instant-rebuilds of Mirage packages. >>> I know it's possible to pull this off with the existing compiler tools, >>> since the monolithic Mirage tree (with lovingly crafted ocamlbuild rules >>> and judicious use of native code compiler binaries) could rebuild the >>> entire webserver in ~10s in parallel. Nowadays, with OPAM, ocamlbuild, >>> ocamlfind and camlp4, it takes around 2-3 minutes, which just isn't >>> good enough. >>> >>> -anil >>> >>> [1] http://opam.ocamlpro.com/pkg/debug-camlp4-log.base.html: I hacked >>> up a debug camlp4 to trace all the uses of camlp4 in the OPAM repository, >>> during the wg-camlp4 discussion on the topic of where to go next with it. >>> This just required doing a mass OPAM install, drinking some coffee, and >>> reading the resulting trace logs. >>> >>> -- >>> Caml-list mailing list. Subscription management and archives: >>> https://sympa.inria.fr/sympa/arc/caml-list >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- > Wojciech