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