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

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

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

I'm not convinced by the starting point of this discussion. Why would we
need a consensus on a single build system? It seems to me that build
systems are fine as per-project choices; I don't lose much if some other
project uses another build system. The libraries I rely on may use any
build system they like, it doesn't affect my own work.


Of course there is also a question of the workforce supporting any given
build system. OCamlbuild for example could certainly do with more people
improving the tool; but it seems highly unclear that developers working
today on tool X would contribute on tool Y if X didn't exist.

(Fragmentation of, say, standard libraries seem more problematic as it
tends to create separate ecosystems.)


PS:

> if ocamlbuild were spun out of the compiler, could it be enhanced to
cover all the main use-cases so (almost) everyone would be happy with it

OCamlbuild accepts patches today (through caml-list, mantis, or as github
pull requests). There is no reason to wait for the "spinning out" to
contribute.

On Wed, Sep 10, 2014 at 9:56 PM, Sebastien Mondet <
sebastien.mondet@gmail.com> wrote:

>
>
> On Wed, Sep 10, 2014 at 3:16 PM, Peter Zotov <whitequark@whitequark.org>
> wrote:
>
>> On 2014-09-10 22:59, Yotam Barnoy wrote:
>>
>>> ocp-build actually looks very interesting. The manual (which is here:
>>> http://github.com/OCamlPro/ocp-build/blob/master/docs/
>>> user-manual/user-manual.pdf?raw=true
>>> [2]) is incomplete, but contains a nice survey of the existing build
>>> tools, and motivation for making ocp-build. Has anyone had experience
>>> with ocp-build? Opam seems to be using it, but they also use a
>>> makefile (why?) with a bunch of shell commands inside (which is
>>> precisely the problem from my perspective). ocp-build is supposedly
>>> compatible with Windows, too.
>>>
>>
>> Every single time I had to use ocp-build, it broke in an odd and hard to
>> fix way. It was so bad that eventually I just ported the ocp-build-using
>> projects (ocp-index and its dependencies) to OASIS. Most worryingly it has
>> some strange requirement to ship bytecode, which ties it to a released
>> OCaml
>> version; no other buildsystem needs that.
>>
>>
> Yes ocp-build is broken for many corner cases, I've been trying to push it
> to its maximum; look at that ugly shell script:
> https://github.com/hammerlab/ketrew/blob/master/please.sh that even has
> to create a yojson library out of the one in ~/.opam to please ocp-build's
> assumptions.
>
> Also, like every build system based on flat files (oasis, obuild), it is
> fundamentally broken. You'll always need a programming language to extended
> your build (adding targets, like build documentation/websites, special
> tests, .merlin files, code generation...).
>
> - omake did that with yet another obscure and weird language (I guess the
> goal was to "look" like `make` but with even more broken string escaping).
> - ocamlbuild and jenga picked the right language.
>     - ocamlbuild's API is very limited, there is not even a clear way to
> replace all the crazy small files required everywhere (_tags, mllib, ...)
> with function calls within a myocamlbuild.ml plugin. It is also painfully
> slow.
>     - Jenga is not for "normal" projects. It takes half-an-hour to build
> jenga itself, and it's dependency tree is not very portable. The API is
> very convoluted even for simple projects.
>
> Look at https://github.com/samoht/assemblage/ certainly going to in the
> right direction.
>
>
>
>
>
>
>> --
>> Peter Zotov
>>
>>
>> --
>> 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: 5769 bytes --]