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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id A2EEB817AE for ; Wed, 24 Jul 2013 18:39:25 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQMAAsC8FFZELGadGdsb2JhbABagzuqcJM+AwGBLA4BDBUIPIIkAQEBAwEBAQFrCwULC0YhBgEvBhOHfgMJCgiwGg2IXo0VGYFkaweDEm4DiSqLbl6BaYEpin6IWhw X-IPAS-Result: AqQMAAsC8FFZELGadGdsb2JhbABagzuqcJM+AwGBLA4BDBUIPIIkAQEBAwEBAQFrCwULC0YhBgEvBhOHfgMJCgiwGg2IXo0VGYFkaweDEm4DiSqLbl6BaYEpin6IWhw X-IronPort-AV: E=Sophos;i="4.89,736,1367964000"; d="scan'208";a="22151104" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail3-smtp-sop.national.inria.fr with SMTP; 24 Jul 2013 18:39:24 +0200 Received: (qmail 11841 invoked by uid 634); 24 Jul 2013 16:39:24 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from ip-64-134-140-73.public.wayport.net (HELO [192.168.4.176]) (64.134.140.73) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Wed, 24 Jul 2013 17:39:23 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 24 Jul 2013 09:39:19 -0700 Cc: Thomas Gazagnaire , Gerd Stolpmann , Fabrice Le Fessant , Francois Berenger , Ocaml Mailing List Content-Transfer-Encoding: 7bit Message-Id: <7F8931D5-E65D-49EB-B54D-A50716F3EFDD@recoil.org> References: <1374669368.25411.5@samsung> <1B6BB035-9909-4F0C-9DEA-F713B977A467@ocamlpro.com> To: Markus Mottl X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] GODI is shutting down 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.