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

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Le jeudi, 18 septembre 2014 à 23:36, Yaron Minsky a écrit :
> Generating Jenga rules or OMake rules I think is note quite the right
> approach. That's because Jenga and OMake both use general purpose
> programming languages for specifying builds, and I think you'll get
> bad behavior if you try to treat that language as a compilation
> target.
>  
> For Jenga, I think it's better to write a Jenga plug-in for reading
> Assemblage files. It has the same effect, but is an easier and more
> typeful programming experience than spitting out a bunch of OCaml AST.

Yes that seems much more sensitive. I'm currently working on the API and everything will be exposed to allow you to do that. We'll just need to figure out a way so that you can easily take a handle on the project description value.

Usually I don't comment or advertise unfinished things but I'd also like to point out that the goal with assemblage is also a little bit larger than just generating a build system. I'd like to be able to express most of the package release and installation process inside it (or at least provide helpers to do so) in order to replace all the ad-hoc scripts that is use now (e.g. topkg), to make quick and flawless releases by gathering information from the right places, tags in the vcs for version information, synchronizing opam file with correct package dependencies, opam-submit integration etc.  

Some people do find my release process complex, I basically apply a function on a git checkout and do ugly things like a global key value substitution on all the files, but at least it is flawless and traceable. For example package never lie to you about their current version, even if you pin them. The only way to get that flawlessly is to automate it — can't count the number of times opam lied to me about its version because its version number needs to be bumped manually.

Last year I tried the other new build systems and to influence them in that direction (e.g. generating .install files) without much success. I guess most people don't understand these problem as they only publish one package or two and can afford to spend some time to do their releases or hack an install process. I can't. That being said, I think we should not rush on that one, it will be ready when it is ready, (I personally soon won't have the time to work on this as I'll have to earn my life for the winter, I can't speak for Thomas though).

> I think consensus should follow code, not the other way around.
Yes. That whole discussion is largely pointless. Some people don't get that healthy online communities self-organize.

Daniel