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 20CEB7FACD for ; Fri, 19 Sep 2014 14:31:52 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUCAOcgHFRKN1ZKnGdsb2JhbABghhaBIs42AYEYAREBAQEBAQYNCQkUKoQEAQEDASNWBQsLDgwCJgICRxAGGxGIHQgErFWWPAEXgSyOIjMHgng2gR0FkliFcYt+GJFjgzQBAQE X-IPAS-Result: AvUCAOcgHFRKN1ZKnGdsb2JhbABghhaBIs42AYEYAREBAQEBAQYNCQkUKoQEAQEDASNWBQsLDgwCJgICRxAGGxGIHQgErFWWPAEXgSyOIjMHgng2gR0FkliFcYt+GJFjgzQBAQE X-IronPort-AV: E=Sophos;i="5.04,554,1406584800"; d="scan'208";a="96633755" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail2-smtp-roc.national.inria.fr with ESMTP; 19 Sep 2014 14:31:51 +0200 Received: from [192.168.0.15] (bbcs-167-211.cust.wingo.ch [178.238.167.211]) by smtp.webfaction.com (Postfix) with ESMTP id 8FA842296755; Fri, 19 Sep 2014 12:31:48 +0000 (UTC) Date: Fri, 19 Sep 2014 14:31:48 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Yaron Minsky Cc: Ocaml Mailing List Message-ID: In-Reply-To: References: <5410522E.3050207@inria.fr> <1410359012.3003.34.camel@thinkpad> <54106B6D.4040607@gmail.com> <5416EAF8.9050800@glondu.net> <353DB638-1E30-40B6-BE5D-EA4479E009FB@recoil.org> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] One build system to rule them all? Le jeudi, 18 septembre 2014 =C3=A0 23:36, Yaron Minsky a =C3=A9crit : > Generating Jenga rules or OMake rules I think is note quite the right > approach. That's because Jenga and OMake both use general purpose > programming languages for specifying builds, and I think you'll get > bad behavior if you try to treat that language as a compilation > target. >=20=20 > For Jenga, I think it's better to write a Jenga plug-in for reading > Assemblage files. It has the same effect, but is an easier and more > typeful programming experience than spitting out a bunch of OCaml AST. Yes that seems much more sensitive. I'm currently working on the API and ev= erything will be exposed to allow you to do that. We'll just need to figure= out a way so that you can easily take a handle on the project description = value. Usually I don't comment or advertise unfinished things but I'd also like to= point out that the goal with assemblage is also a little bit larger than j= ust generating a build system. I'd like to be able to express most of the p= ackage release and installation process inside it (or at least provide help= ers to do so) in order to replace all the ad-hoc scripts that is use now (e= .g. topkg), to make quick and flawless releases by gathering information fr= om the right places, tags in the vcs for version information, synchronizing= opam file with correct package dependencies, opam-submit integration etc.= =20=20 Some people do find my release process complex, I basically apply a functio= n on a git checkout and do ugly things like a global key value substitution= on all the files, but at least it is flawless and traceable. For example p= ackage never lie to you about their current version, even if you pin them. = The only way to get that flawlessly is to automate it =E2=80=94 can't count= the number of times opam lied to me about its version because its version = number needs to be bumped manually. Last year I tried the other new build systems and to influence them in that= direction (e.g. generating .install files) without much success. I guess m= ost people don't understand these problem as they only publish one package = or two and can afford to spend some time to do their releases or hack an in= stall process. I can't. That being said, I think we should not rush on that= one, it will be ready when it is ready, (I personally soon won't have the = time to work on this as I'll have to earn my life for the winter, I can't s= peak for Thomas though). > I think consensus should follow code, not the other way around. Yes. That whole discussion is largely pointless. Some people don't get that= healthy online communities self-organize. Daniel