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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6362 bytes --]

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).



> 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
>

[-- Attachment #2: Type: text/html, Size: 8365 bytes --]