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