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 9FACB7FACD for ; Fri, 19 Sep 2014 09:28:04 +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.219.53; 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.219.53 as permitted sender) identity=mailfrom; client-ip=209.85.219.53; 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-oa0-f53.google.com) identity=helo; client-ip=209.85.219.53; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-oa0-f53.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUCAKTZG1TRVds1lGdsb2JhbABgg2BXBIJ9tRGPVYFrh00BgQIIFgERAQEBAQcLCwkSLIQDAQEBAwESER0BGxACCAMBAwELBgULAwoNHQICIQEBEQEFAQoSBhMICgIHB4gHAQMJCA2faWuLMIFygxCJNgoZJwMKZoZIAREBBQ6KB4M1gikEB4J4gVMBBIRbMgIDiiaDGYM0hDZBghCBYI0mhFAYKYUROy+CSgEBAQ X-IPAS-Result: AlUCAKTZG1TRVds1lGdsb2JhbABgg2BXBIJ9tRGPVYFrh00BgQIIFgERAQEBAQcLCwkSLIQDAQEBAwESER0BGxACCAMBAwELBgULAwoNHQICIQEBEQEFAQoSBhMICgIHB4gHAQMJCA2faWuLMIFygxCJNgoZJwMKZoZIAREBBQ6KB4M1gikEB4J4gVMBBIRbMgIDiiaDGYM0hDZBghCBYI0mhFAYKYUROy+CSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,553,1406584800"; d="scan'208";a="80014068" Received: from mail-oa0-f53.google.com ([209.85.219.53]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Sep 2014 09:28:03 +0200 Received: by mail-oa0-f53.google.com with SMTP id eb12so1403892oac.26 for ; Fri, 19 Sep 2014 00:28:01 -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=ZkwEFgJywHh1C/ouNQM47Z/KGuFOQeagIWfK+hRjNPo=; b=UD3h9S/NyUb/EfF0lz1Z9UhP75tIbe65xeNFAisnCyV3LKSRPYvIa+iX3Q7dTkspyw pUeyFz+qiTpgSlGkFj/r2uGsltSnpj6W/Y8YrFxXzb4VarIwvMFD+qbSF9Y/Jn3mp0uu NW2cMCl0HeNewoJtOWNZN0Tu0k/K8qaRH+oqO/Yv4adYU3Zk7muZsg+07/mgFoKfpX/F MR4+7PWc7FGNfxfNtyT2xRvZsH+iy4H+qwJ69LvNVAm8Edo+aWkFL2Rgewj/CbroWYml qAF0L9Wn3bSGXw/uo6lU0AXQt/f58lPLStmZ+ulURcG/5Xsf5tl1Y59AsU/A7rpvpJXy JzfA== X-Received: by 10.182.142.40 with SMTP id rt8mr2051911obb.80.1411111681532; Fri, 19 Sep 2014 00:28:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.141.165 with HTTP; Fri, 19 Sep 2014 00:27:21 -0700 (PDT) In-Reply-To: References: <5410522E.3050207@inria.fr> <1410359012.3003.34.camel@thinkpad> <54106B6D.4040607@gmail.com> <5416EAF8.9050800@glondu.net> From: Gabriel Scherer Date: Fri, 19 Sep 2014 09:27:21 +0200 Message-ID: To: Yaron Minsky Cc: Yotam Barnoy , Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c2de6e8428cc0503660a65 Subject: Re: [Caml-list] One build system to rule them all? --001a11c2de6e8428cc0503660a65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 18, 2014 at 11:23 PM, Yaron Minsky wrote: > Rather than exhort everyone to focus in on a solution, I recommend you > pick the one you think looks best, and see if you can contribute to > it. > Agreed. My very personal point of focus is to help current ocamlbuild users (there are a fair number of them) is there a DSL-based build system that we can converge on to use and > improve? > I think this distinction between ocaml-using and DSL-using build systems does not matter in the long run. It matters when you look at a tool at a given point in time, but here you are discussing the long-term evolution of the tooling, and those distinctions get blurred assuming enough contributions: 1) you can turn an ocaml-using build system into a DSL-using build system by having an input mode that take DSL descriptions instead of rules, and interpreting them in term of those rules 2) a well-designed DSL-based system has an underlying library encoding the tool's engines, and exposing this library to advanced users effectively turns it into an ocaml-using tool as well Conversely, continuing to spread the community's attention between these > tools (as well as ocamlbuild, which seems destined to stagnate) before any > one of them is top notch seems to me to be detrimental to ocaml's health = as > an ecosystem. I haven't seen any good reason in this thread justifying ocamlbuild's stagnation (except, of course, the fact that few people are currently interested in working on that; but I thought you tried to abstract from this aspect): - people have mentioned having to edit several files as a source of annoyance with ocamlbuild; it would be rather easy to work on having a file with sub-sections corresponding to several of today's configuration file - the disappointing parallelism has been mentioned as a problem with ocamlbuild's implementation today -- it is a problem. I have discussed a practical approach to improving parallelism in ( http://gallium.inria.fr/blog/ocamlbuild-parallelization/ ), which would require a bit more work but is not out of reach. For example that would be a reasonable Google Summer of Code (GSoC) topic, had the community succeeded in establishing a presence at GSoC. Note that I am not particularly attached to ocamlbuild in its current state; I care about its users to which it provides good service and should not be left in the dust. Jenga's design is in fact surprisingly close to ocamlbuild's, and one thing I have been thinking about is trying to reimplement ocamlbuild as a kind of "frontend" on top of Jenga's implementation -- the goal being the maintain compatibility with existing ocamlbuild setups, and gain some of the benefits of Jenga's engineering resources, namely arguably better parallelization and support continuous build. That's a rather bold move, there would be many less invasive changes that could have a positive impact on users -- for example, turning a succesful build into a Makefile should be doable in ocamlbuild as well, and interesting for many reasons (bare-boneness, performances). > I think consensus should follow code, not the other way around. > > y > > On Thu, Sep 18, 2014 at 5:15 PM, Yotam Barnoy > wrote: > > While there was no 'conclusion' to this thread, if I had to come up with > > one, it would be that we have a bunch of build tools which are all not > > amazing at this point in time. We have some DSL-based build tools and > some > > ocaml-based build tools, and all of them need a lot of love to get to a > good > > state. > > > > My personal view is that we (as a community) should work at getting at > least > > one DSL tool to be really great. I'm sure Jenga (an ocaml-based tool > which > > seems more like a build-tool engine) will continue to be developed by > Jane > > Street no matter what, so is there a DSL-based build system that we can > > converge on to use and improve? The contenders for this slot appear to = be > > omake, obuild, and ocp-build. I'm more than willing to switch to one of > > these if I know that other people will as well, and that it will be > actively > > developed (preferably on github). More users =3D more invested parties = =3D > more > > development potential. Conversely, continuing to spread the community's > > attention between these tools (as well as ocamlbuild, which seems > destined > > to stagnate) before any one of them is top notch seems to me to be > > detrimental to ocaml's health as an ecosystem. > > > > BTW Anil: is assemblage supposed to be an entire build toolchain, or is > it > > only supposed to write makefiles (as the description in the readme > states)? > > > > -Yotam > > > > On Mon, Sep 15, 2014 at 9:34 AM, St=C3=A9phane Glondu > wrote: > >> > >> Le 10/09/2014 20:59, Yotam Barnoy a =C3=A9crit : > >> > So here are some requirements I can think of (using some of the > >> > suggestions that have been brought up): > >> > - Easy to use, especially for small projects (large projects can > afford > >> > to put more time into their build systems) > >> > - Abstract away platform considerations as much as possible. No > >> > dependence on specific shells and POSIX utilities. > >> > - Allows compilation of C files, which is quite common in ocaml > >> > packages. > >> > - Scalable to many directories and files > >> > - Uses ocamlfind to locate packages > >> > - Handles camlp4 and ppx > >> > - Parallel & incremental compilation > >> > >> - Support of platforms without ocamlopt. Many build systems assume th= at > >> ocamlopt is available and have to be called specially (or even patched) > >> when it is missing, which complicates packaging on these platforms. > >> > >> -- > >> St=C3=A9phane > >> > >> -- > >> 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 > > > > > > -- > 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 > --001a11c2de6e8428cc0503660a65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 18, 2014 at 11:23 PM, Yaron Minsky <ym= insky@janestreet.com> wrote:
Rather than exhort everyone to focus in on a solution, I recommend you
pick the one you think looks best, and see if you can contribute to
it.

Agreed.

My very p= ersonal point of focus is to help current ocamlbuild users (there are a fai= r number of them)

is there a=20 DSL-based build system that we can converge on to use and improve?

I think this distinction between ocaml-using and DSL= -using build systems does not matter in the long run. It matters when you l= ook at a tool at a given point in time, but here you are discussing the lon= g-term evolution of the tooling, and those distinctions get blurred assumin= g enough contributions:
1) you can turn an ocaml-using build = system into a DSL-using build system by having an input mode that take DSL = descriptions instead of rules, and interpreting them in term of those rules=
2) a well-designed DSL-based system has an underlying librar= y encoding the tool's engines, and exposing this library to advanced us= ers effectively turns it into an ocaml-using tool as well

Conversely, continuing to spread th= e community's attention=20 between these tools (as well as ocamlbuild, which seems destined to=20 stagnate) before any one of them is top notch seems to me to be=20 detrimental to ocaml's health as an ecosystem.

I haven't seen any good reason in this thread justifying ocamlb= uild's stagnation (except, of course, the fact that few people are curr= ently interested in working on that; but I thought you tried to abstract fr= om this aspect):
- people have mentioned having to edit sever= al files as a source of annoyance with ocamlbuild; it would be rather easy = to work on having a file with sub-sections corresponding to several of toda= y's configuration file
- the disappointing parallelism ha= s been mentioned as a problem with ocamlbuild's implementation today --= it is a problem. I have discussed a practical approach to improving parall= elism in ( http://gallium.inria.fr/blog/ocamlbuild-parallelization/ ), which = would require a bit more work but is not out of reach. For example that wou= ld be a reasonable Google Summer of Code (GSoC) topic, had the community su= cceeded in establishing a presence at GSoC.

No= te that I am not particularly attached to ocamlbuild in its current state; = I care about its users to which it provides good service and should not be = left in the dust.

Jenga's design is in fact surprisingly close t= o ocamlbuild's, and one thing I have been thinking about is trying to r= eimplement ocamlbuild as a kind of "frontend" on top of Jenga'= ;s implementation -- the goal being the maintain compatibility with existin= g ocamlbuild setups, and gain some of the benefits of Jenga's engineeri= ng resources, namely arguably better parallelization and support continuous= build. That's a rather bold move, there would be many less invasive ch= anges that could have a positive impact on users -- for example, turning a = succesful build into a Makefile should be doable in ocamlbuild as well, and= interesting for many reasons (bare-boneness, performances).

= =C2=A0
I think consensus should follow code, not the other way around.

y

On Thu, Sep 18, 2014 at 5:15 PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> While there was no 'conclusion' to this thread, if I had to co= me up with
> one, it would be that we have a bunch of build tools which are all not=
> amazing at this point in time. We have some DSL-based build tools and = some
> ocaml-based build tools, and all of them need a lot of love to get to = a good
> state.
>
> My personal view is that we (as a community) should work at getting at= least
> one DSL tool to be really great. I'm sure Jenga (an ocaml-based to= ol which
> seems more like a build-tool engine) will continue to be developed by = Jane
> Street no matter what, so is there a DSL-based build system that we ca= n
> converge on to use and improve? The contenders for this slot appear to= be
> omake, obuild, and ocp-build. I'm more than willing to switch to o= ne of
> these if I know that other people will as well, and that it will be ac= tively
> developed (preferably on github). More users =3D more invested parties= =3D more
> development potential. Conversely, continuing to spread the community&= #39;s
> attention between these tools (as well as ocamlbuild, which seems dest= ined
> to stagnate) before any one of them is top notch seems to me to be
> detrimental to ocaml's health as an ecosystem.
>
> BTW Anil: is assemblage supposed to be an entire build toolchain, or i= s it
> only supposed to write makefiles (as the description in the readme sta= tes)?
>
> -Yotam
>
> On Mon, Sep 15, 2014 at 9:34 AM, St=C3=A9phane Glondu <steph@glondu.net> wrote:
>>
>> Le 10/09/2014 20:59, Yotam Barnoy a =C3=A9crit :
>> > So here are some requirements I can think of (using some of t= he
>> > suggestions that have been brought up):
>> > - Easy to use, especially for small projects (large projects = can afford
>> > to put more time into their build systems)
>> > - Abstract away platform considerations as much as possible. = No
>> > dependence on specific shells and POSIX utilities.
>> > - Allows compilation of C files, which is quite common in oca= ml
>> > packages.
>> > - Scalable to many directories and files
>> > - Uses ocamlfind to locate packages
>> > - Handles camlp4 and ppx
>> > - Parallel & incremental compilation
>>
>>=C2=A0 - Support of platforms without ocamlopt. Many build systems = assume that
>> ocamlopt is available and have to be called specially (or even pat= ched)
>> when it is missing, which complicates packaging on these platforms= .
>>
>> --
>> St=C3=A9phane
>>
>> --
>> Caml-list mailing list.=C2=A0 Subscription management and archives= :
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginner= s
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
ht= tps://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
--001a11c2de6e8428cc0503660a65--