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 1AF207F75C for ; Wed, 10 Sep 2014 22:16:30 +0200 (CEST) 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.177; 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.177 as permitted sender) identity=mailfrom; client-ip=209.85.214.177; 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-ob0-f177.google.com) identity=helo; client-ip=209.85.214.177; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ob0-f177.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIBAKCwEFTRVdaxm2dsb2JhbABfg2BbgnixITKEApAKgWuHSwGBCggWEAEBAQEBBgsLCRQqhAMBAQECAQESBgsdARsSCwEDAQsGBQsNDR0CAiEBAREBBQEKEgYTEhCICwEDCQgNnVFrizCBcoMQiHkKGScDCmaFcgERAQUOjRKBVVQEB4J5gVMFhQsFjTqDL4RzghCBX40dhEsYKYJ5ghs7L4EGgUkBAQE X-IPAS-Result: AkIBAKCwEFTRVdaxm2dsb2JhbABfg2BbgnixITKEApAKgWuHSwGBCggWEAEBAQEBBgsLCRQqhAMBAQECAQESBgsdARsSCwEDAQsGBQsNDR0CAiEBAREBBQEKEgYTEhCICwEDCQgNnVFrizCBcoMQiHkKGScDCmaFcgERAQUOjRKBVVQEB4J5gVMFhQsFjTqDL4RzghCBX40dhEsYKYJ5ghs7L4EGgUkBAQE X-IronPort-AV: E=Sophos;i="5.04,501,1406584800"; d="scan'208";a="78487588" Received: from mail-ob0-f177.google.com ([209.85.214.177]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Sep 2014 22:16:28 +0200 Received: by mail-ob0-f177.google.com with SMTP id wp4so648253obc.36 for ; Wed, 10 Sep 2014 13:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8SlvZhSEUOqjJOJTYBfYFe4tVZCLUXjyj8srli2pY/s=; b=l9YsXG7jWARRMVELblpNfedl0SSim7EvS2oO1+02pqlBBVbbIl5yoeDJJaMBElyl/M 9oP5ADZXsgWqBeRG7KW+oTugBg0ZLm0yw2GhE7PGnVv2rdsHhAbPts71Fy77agJJB6Os V9JbRjCWdcwT6QVOSM4XN3cmhnsUYqdwDOSwKFlS87liXUVxNbrpnPnTQJIo/I6MYKzI mSR+7NpvngHXPA8TqhfEyR+mGTXT6h/1eGk+HUEU9TbDfnQKY8Zl8pxle9TL12TE3b4E S0EJcBY7VZGqyiwK9Oif1azeH/xBIDgvTg4JB5YvidUXZYHI/XSgvORO5eWhpD2Od6n2 TBRA== X-Received: by 10.60.45.7 with SMTP id i7mr22895474oem.2.1410380187330; Wed, 10 Sep 2014 13:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.141.165 with HTTP; Wed, 10 Sep 2014 13:15:47 -0700 (PDT) In-Reply-To: References: <5410522E.3050207@inria.fr> <1410359012.3003.34.camel@thinkpad> <54106B6D.4040607@gmail.com> From: Gabriel Scherer Date: Wed, 10 Sep 2014 22:15:47 +0200 Message-ID: To: Sebastien Mondet Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=089e0149cb921074160502bbba56 Subject: Re: [Caml-list] One build system to rule them all? --089e0149cb921074160502bbba56 Content-Type: text/plain; charset=UTF-8 I'm not convinced by the starting point of this discussion. Why would we need a consensus on a single build system? It seems to me that build systems are fine as per-project choices; I don't lose much if some other project uses another build system. The libraries I rely on may use any build system they like, it doesn't affect my own work. Of course there is also a question of the workforce supporting any given build system. OCamlbuild for example could certainly do with more people improving the tool; but it seems highly unclear that developers working today on tool X would contribute on tool Y if X didn't exist. (Fragmentation of, say, standard libraries seem more problematic as it tends to create separate ecosystems.) PS: > if ocamlbuild were spun out of the compiler, could it be enhanced to cover all the main use-cases so (almost) everyone would be happy with it OCamlbuild accepts patches today (through caml-list, mantis, or as github pull requests). There is no reason to wait for the "spinning out" to contribute. On Wed, Sep 10, 2014 at 9:56 PM, Sebastien Mondet < sebastien.mondet@gmail.com> wrote: > > > On Wed, Sep 10, 2014 at 3:16 PM, Peter Zotov > wrote: > >> On 2014-09-10 22:59, Yotam Barnoy wrote: >> >>> ocp-build actually looks very interesting. The manual (which is here: >>> http://github.com/OCamlPro/ocp-build/blob/master/docs/ >>> user-manual/user-manual.pdf?raw=true >>> [2]) is incomplete, but contains a nice survey of the existing build >>> tools, and motivation for making ocp-build. Has anyone had experience >>> with ocp-build? Opam seems to be using it, but they also use a >>> makefile (why?) with a bunch of shell commands inside (which is >>> precisely the problem from my perspective). ocp-build is supposedly >>> compatible with Windows, too. >>> >> >> Every single time I had to use ocp-build, it broke in an odd and hard to >> fix way. It was so bad that eventually I just ported the ocp-build-using >> projects (ocp-index and its dependencies) to OASIS. Most worryingly it has >> some strange requirement to ship bytecode, which ties it to a released >> OCaml >> version; no other buildsystem needs that. >> >> > Yes ocp-build is broken for many corner cases, I've been trying to push it > to its maximum; look at that ugly shell script: > https://github.com/hammerlab/ketrew/blob/master/please.sh that even has > to create a yojson library out of the one in ~/.opam to please ocp-build's > assumptions. > > Also, like every build system based on flat files (oasis, obuild), it is > fundamentally broken. You'll always need a programming language to extended > your build (adding targets, like build documentation/websites, special > tests, .merlin files, code generation...). > > - omake did that with yet another obscure and weird language (I guess the > goal was to "look" like `make` but with even more broken string escaping). > - ocamlbuild and jenga picked the right language. > - ocamlbuild's API is very limited, there is not even a clear way to > replace all the crazy small files required everywhere (_tags, mllib, ...) > with function calls within a myocamlbuild.ml plugin. It is also painfully > slow. > - Jenga is not for "normal" projects. It takes half-an-hour to build > jenga itself, and it's dependency tree is not very portable. The API is > very convoluted even for simple projects. > > Look at https://github.com/samoht/assemblage/ certainly going to in the > right direction. > > > > > > >> -- >> Peter Zotov >> >> >> -- >> 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 >> > > --089e0149cb921074160502bbba56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not convinced by the starting point of t= his discussion. Why would we need a consensus on a single build system? It = seems to me that build systems are fine as per-project choices; I don't= lose much if some other project uses another build system. The libraries I= rely on may use any build system they like, it doesn't affect my own w= ork.


Of course there is also a question of the workforce s= upporting any given build system. OCamlbuild for example could certainly do= with more people improving the tool; but it seems highly unclear that deve= lopers working today on tool X would contribute on tool Y if X didn't e= xist.

(Fragmentation of, say, standard libraries seem mor= e problematic as it tends to create separate ecosystems.)

PS:

> if ocamlbuild were spun out of the compiler, could it = be enhanced to=20 cover all the main use-cases so (almost) everyone would be happy with it
OCamlbuild accepts patches today (through caml-list, mantis, o= r as github pull requests). There is no reason to wait for the "spinni= ng out" to contribute.

On Wed, Sep 10, = 2014 at 9:56 PM, Sebastien Mondet <sebastien.mondet@gmail.com= > wrote:

<= div class=3D"gmail_extra">
O= n Wed, Sep 10, 2014 at 3:16 PM, Peter Zotov <whitequark@whitequa= rk.org> wrote:
On 2014-09-10 22:59, Yotam Barnoy wrote:
ocp-build actually looks very interesting. The manual (which is here:
http://github.com/OCamlPro/= ocp-build/blob/master/docs/user-manual/user-manual.pdf?raw=3Dtrue
 [2]) is incomplete, but contains a nice survey of the existing build<= br> tools, and motivation for making ocp-build. Has anyone had experience
with ocp-build? Opam seems to be using it, but they also use a
makefile (why?) with a bunch of shell commands inside (which is
precisely the problem from my perspective). ocp-build is supposedly
compatible with Windows, too.

Every single time I had to use ocp-build, it broke in an odd and hard to
fix way. It was so bad that eventually I just ported the ocp-build-using
projects (ocp-index and its dependencies) to OASIS. Most worryingly it has<= br> some strange requirement to ship bytecode, which ties it to a released OCam= l
version; no other buildsystem needs that.


Yes ocp-build is broken for = many corner cases, I've been trying to push=20 it to its maximum; look at that ugly shell script:=20 https://github.com/hammerlab/ketrew/blob/master/please.sh = that even has=20 to create a yojson library out of the one in ~/.opam to please ocp-build= 9;s assumptions.

Also, like every build system based on f= lat files (oasis, obuild), it is fundamentally broken. You'll always ne= ed a programming language to extended your build (adding targets, like buil= d documentation/websites, special tests, .merlin files, code generation...)= .

- omake did that with yet another obscure an= d weird language (I guess the goal was to "look" like `make` but = with even more broken string escaping).
- ocamlbuild and jeng= a picked the right language.
=C2=A0=C2=A0=C2=A0 - ocamlbuild&= #39;s API is very limited, there is not even a clear way to replace all the= crazy small files required everywhere (_tags, mllib, ...) with function ca= lls within a myocamlbu= ild.ml plugin. It is also painfully slow.
=C2=A0=C2=A0=C2= =A0 - Jenga is not for "normal" projects. It takes half-an-hour t= o build jenga itself, and it's dependency tree is not very portable. Th= e API is very convoluted even for simple projects.

Look a= t https= ://github.com/samoht/assemblage/ certainly going to in the right direct= ion.




=C2=A0
--
Peter Zotov


--089e0149cb921074160502bbba56--