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 80EFC7F30A for ; Sun, 10 Mar 2013 21:55:48 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.48 as permitted sender) identity=mailfrom; client-ip=209.85.214.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f48.google.com) identity=helo; client-ip=209.85.214.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIBABPyPFHRVdYwiGdsb2JhbABCxESBQwgWDgEBAQoJFBQEJIImAQEFQAEbHQEDDAYFCw0jCyEBAREBBQEcBhOIAAEDDwyeGIwygnuDZwoZJw1ZiHwBBQyMOoJIB4NAA5JWgh+BYIEeij6DNxYpgneBNzs X-IPAS-Result: AmIBABPyPFHRVdYwiGdsb2JhbABCxESBQwgWDgEBAQoJFBQEJIImAQEFQAEbHQEDDAYFCw0jCyEBAREBBQEcBhOIAAEDDwyeGIwygnuDZwoZJw1ZiHwBBQyMOoJIB4NAA5JWgh+BYIEeij6DNxYpgneBNzs X-IronPort-AV: E=Sophos;i="4.84,819,1355094000"; d="scan'208";a="4852636" Received: from mail-bk0-f48.google.com ([209.85.214.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Mar 2013 21:55:47 +0100 Received: by mail-bk0-f48.google.com with SMTP id jf20so1380153bkc.7 for ; Sun, 10 Mar 2013 13:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=+USi+hD1BqPS96LyjpRqRKjibies7jIXDipt8aphVcY=; b=alpVoinveRPBrJ2CMOulclmR1088xTtHCOGEEBqtzgox7u0a8bgd1PwBLDoNutEn8n J3Vl8VlJRbITg9ht5gflTKEfqLlqai8MwX/mVOEAo9e/E+gMPKYYqEo4PINkmuNfWJHV N+IC3kZyHqaYUjUn3wgikVVTnfXoZydgxi1qfwtzdwpG2+V1dXEvui/drDRaKa6VRHOL pDAfsonrfKH6MY0cOI7qca1fvVkZnaL6cmvvmHjzpV6KzOpiztodzLK4sCjkMN1s3qEe jNu1PiLsAF9W8o/yDRGB2rhGXEUBP9ZjdURWUXpB6gonwk0dq3Tkm/19rH5wYaFX2LeA mUXQ== X-Received: by 10.204.200.131 with SMTP id ew3mr3734120bkb.103.1362948947290; Sun, 10 Mar 2013 13:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.83.144 with HTTP; Sun, 10 Mar 2013 13:55:06 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Sun, 10 Mar 2013 21:55:06 +0100 Message-ID: To: Wojciech Meyer Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] If you distribute oasis' setup.ml with your software, please use a recent (>= 0.3.0) version of Oasis Indeed. The recommendation is rather orthogonal to the choice of maintainers to distribute setup.ml with they released tarball or not. If they don't, fine, if they do, please distribute the setup.ml generated from a recent OASIS. As a downstream user, I would have a preference for people to generate the setup.ml statically on their side (some less work and dependencies for us users), but I understand that just tarballing the development repository is a quick&easy way to push a release, made even easier by github, so it's a reasonable choice -- and I understand that people don't want to clutter their versioned repo with auto-generated files. (The initial reason for my e-mail was benchmarking considerations: we're considering using the OPAM compiler variant system to test in-development branches of the OCaml compiler, which mean possibly tight (edit, compile, opam install, benchmark) cycles. OPAM would be used to install just what's needed for the benchmarks, so maybe one library or two but mostly only the benchmarking library. In this context, it's important to have as few dependencies as possible, and I'm eager to remove the "oasis" dependency of "bench" and "benchmark".) On Sun, Mar 10, 2013 at 8:25 PM, Wojciech Meyer wrote: > One of the reasons why people don't regenerate setup.ml but rely on > Oasis is very prosaic: some of the projects (if not most) are source > hosted on github, but github does not host files, however git tags can be > used to download the tarball using single URL. > > I'd add to Gabriel's suggestion to host these files somewhere, ocamlcore > seems to be like a natural choice. > > Gabriel Scherer writes: > >> The number of packages available through OPAM that list "oasis" as a >> dependency (see list below) is too high -- oasis being designed to let >> developers pre-generate setup.ml to avoid any actual dependency on it. >> >> The reason for this is a glitch in old versions of Oasis (< 0.3.0) >> that makes the generated setup.ml break with OCaml >= 4.00.0; OPAM >> packagers list oasis as a dependency to regenerate a fixed setup.ml at >> compilation time. This is the case in particular for the latest >> versions of the following packages: >> - ANSITerminal* >> - bench* >> - ocaml-expect >> - ocaml-posix-resource >> - ocaml-radixtree >> - ocaml-sqlexpr >> - optimization1d* >> - root1d* >> >> (*): oasis is the only dependency besides the ubiquitous ocamlfind >> >> If you distribute setup.ml in your source releases, please make sure >> that it is generated with a recent version of Oasis (>= 0.3.0). This >> allows to remove oasis (and its four own dependencies) from the >> dependencies of your package. >> >> You can check which version of Oasis a given setup.ml comes from with >> the command: >> ocaml setup.ml -version >> >> If your package provides a setup.ml with version >= 0.3.0, and "oasis >> setup" is still present in the "build" field of OPAM metadata >> description (or "oasis" marked as a dependency for no other reason), >> this is a packaging bug that you should report to the relevant package >> maintainer or on the opam repository bugtracker ( >> https://github.com/OCamlPro/opam-repository/issues/ ). >> >> PS: I learned about the bad interaction between Oasis < 0.3.0 and >> OCaml >= 4.00.0 from Anil Madhavapeddy in the following bugtracker >> item: https://github.com/OCamlPro/opam-repository/issues/496 > > -- > Wojciech Meyer > http://danmey.org