Re: [Caml-list] One build system to rule them all?

[Yaron Minsky <yminsky@janestreet.com>]

On Fri, Sep 19, 2014 at 3:27 AM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> On Thu, Sep 18, 2014 at 11:23 PM, Yaron Minsky <yminsky@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 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).

We would very much welcome that kind of move, and would be happy to help.

>>
>> 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 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 = more invested parties =
>> > 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éphane Glondu <steph@glondu.net>
>> > wrote:
>> >>
>> >> Le 10/09/2014 20:59, Yotam Barnoy a écrit :
>> >> > 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
>> >> that
>> >> ocamlopt is available and have to be called specially (or even patched)
>> >> when it is missing, which complicates packaging on these platforms.
>> >>
>> >> --
>> >> Stéphane
>> >>
>> >> --
>> >> 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
>
>