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 22F087FACD for ; Fri, 19 Sep 2014 15:06:45 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=5.153.225.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=5.153.225.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@bark.recoil.org) identity=helo; client-ip=5.153.225.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@bark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYHAEQpHFQFmeEz/2dsb2JhbABggw1kA0PRNwELdxYBeYQEAQEDAXkFCwtGPQwBDQYTiDYIBMMQAReKGoU0MwcugwCBHQWYSYRKlU6DYGuCSgEBAQ X-IPAS-Result: AhYHAEQpHFQFmeEz/2dsb2JhbABggw1kA0PRNwELdxYBeYQEAQEDAXkFCwtGPQwBDQYTiDYIBMMQAReKGoU0MwcugwCBHQWYSYRKlU6DYGuCSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,554,1406584800"; d="scan'208";a="96642940" Received: from bark.recoil.org ([5.153.225.51]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Sep 2014 15:06:44 +0200 Received: from flick.office (volstagg-0.srg.cl.cam.ac.uk [128.232.32.232]); by bark.recoil.org (OpenSMTPD) with ESMTPSA id 07da26bc; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Fri, 19 Sep 2014 14:07:37 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Anil Madhavapeddy In-Reply-To: Date: Fri, 19 Sep 2014 14:06:41 +0100 Cc: Yaron Minsky , Ocaml Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: =?windows-1252?Q?Daniel_B=FCnzli?= X-Mailer: Apple Mail (2.1878.6) Subject: Re: [Caml-list] One build system to rule them all? On 19 Sep 2014, at 13:31, Daniel B=FCnzli wro= te: > Le jeudi, 18 septembre 2014 =E0 23:36, Yaron Minsky a =E9crit : >> 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 >> 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. >=20 > Yes that seems much more sensitive. I'm currently working on the API and = everything will be exposed to allow you to do that. We'll just need to figu= re out a way so that you can easily take a handle on the project descriptio= n value. >=20 > 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= just generating a build system. I'd like to be able to express most of the= package release and installation process inside it (or at least provide he= lpers 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 = from the right places, tags in the vcs for version information, synchronizi= ng opam file with correct package dependencies, opam-submit integration etc= .=20=20 >=20 > Some people do find my release process complex, I basically apply a funct= ion on a git checkout and do ugly things like a global key value substituti= on on all the files, but at least it is flawless and traceable. For example= package never lie to you about their current version, even if you pin them= . The only way to get that flawlessly is to automate it =97 can't count the= number of times opam lied to me about its version because its version numb= er needs to be bumped manually. I'm in complete agreement here about automating the full release cycle bein= g important. A significant number of bugs in the OPAM repository have been= around fixing broken invariants around out-of-sync metadata (most simply: = remove the files that you installed when you are uninstalled). It should b= e straightforward to automate much of this process, but it currently is ver= y difficult to do so. What excites me about Assemblage is that it provides the very lowest level = of functionality to enable other tools to provide this automation. This ca= n range from file generation (Makefile), acting as a library for other buil= d systems to interface with the package (Jenga, OMake), reliably interfacin= g with third-party tools such as ocamlfind, and also providing an easy exte= nsion mechanism for functionality that is still inflight (such as integrate= d documentation generation). It's going to take a lot of time and effort to bring the global OCaml repos= itories out there into sync, and will probably never fully happen. However= , the aim with Assemblage is to solve the problem for a smaller set of inte= rested people (i.e. Daniel's own repositories, or the Mirage library releas= es) and expand it out from there. For instance, we'd love reliable compila= tion of Mirage on Windows (it is, after all, quite portable), and so this w= ould motivate providing a suitable mechanism to go from an Assemblage proje= ct description to a Windows build (perhaps interfacing with WODI). best, Anil=