Re: [Caml-list] improve omake [was One build system to rule them all]

[Alain Frisch <alain@frisch.fr>]

On 9/23/2014 12:58 PM, Mark Shinwell wrote:
> I think the details are hazy now, but as far as we recall: your
> statement about avoiding recomputation is correct, but a lot of md5sum
> work happened subsequent to each compilation action in serial, within
> the omake process.

Ok, this could affect total compilation built time, not startup (and 
total time when nothing needs to be rebuilt).

> By no means was this the only problem; another, for example, was a
> vast amount of time spent constructing rules for an entire tree even
> if only a small portion was being demanded to be built.

Ok.  Do you remember if you had some clue about the source of 
inefficiency (evaluator, data structure to represent the environment, etc)?

> (Of course, the worst problem with omake was probably the DSL, which
> we found to be wholly unsuitable for large-scale reliable rule
> engineering.  Programmability really is key.)

YMMV.  LexiFi's experience with the omake DSL is that even if sometime 
annoying, it's possible to achieve a reasonable effect with some 
efforts.  At least, the issues with the DSL did not compensate the other 
nice properties of omake.  I assume that other groups have functional 
build systems implemented with omake as well, so if people working on 
omake can improve its performances, it would be an immediate gain. 
That's not to say that we don't keep an eye open on alternative build 
systems such as Jenga (but switching an entire project to a different 
build system is a daunting task, of course).


Alain