Switch to ocamlbuild (and topkg)

[hhugo]

WIP WIP WIP WIP

[kit-ty-kate]

Why having chose topkg over oasis ? What's the differences in this case ?

[Drup]

You're going to have to give really really good arguments for using this instead of the other PR with oasis. Especially considering the fact that two ocsigen projects switched to oasis already.

[hhugo]

This PR is just an update (with the dev version) of the previous similar PR.
I've just removed "ocamlbuild does all the installation" by an experiment with topkg.
I'll update the oasis PR soon (based this one)

People, please wait !!! :)

[kit-ty-kate]

Ok ok :)

[Drup]

Fair enough, but I still would like a little write up at the end to give your opinions on relative strength and weaknesses of the two packaging system. :p
I have no doubts that oasis has something to learn in term of flexibility.

[gasche]

My own (admittedly subjective) problem with _oasis is that committing auto-generated code into the version-control system gives me the willies. I know that recent versions of _oasis supposedly solve that problem, but I was recently (when I micro-packaged bytes-compat) in position to search for good examples of such software packaging in the wild, and I didn't find what I was looking for. I'll have to admit that from that (perfectionist) point of view, topkg is a seductive option.

It's less of a problem for released tarballs where I feel better about including setup.ml which of course does a lot of nice things, among which simplifying the packaging proper and providing a standard set of feature that the developer doesn't have to be familiar with -- eg. native plugins.

[Drup]

@gasche : https://github.com/ocsigen/tyxml ? only Makefile, configure and setup.ml are generated code and setup.ml is quite small. I think you will agree that the first two are unavoidable.
_tags and myocamlbuild contain only genuine code.
A Makefile.dist is here to do the real release (with a non dynamic setup).

Of course, it means you need oasis to compile the dev version.

[dbuenzli]

Ok this OT. But @Drup for a pure OCaml project ? That seems completely overkill to me.

I don't understand this obsession of configuring and generating build systems with meta-tools (especially when this meta tool itself is over 18'000 loc, more than opam btw). Use and learn to use your build system directly. Layers of indirection always make it harder to understand a system when things go wrong, and especially when these layers are machine generated. Build systems should be obvious in their operating mode.

I think a build system should always be ready to build anything it may need to build (i.e. there should be no configure step), then the package builder should simply invoke the right targets in the build system according to a build environment. To sum up I see the following three components and they should be kept cleanly separated in my opinion:

• Build system, only cares about building artefacts.
• Build environment discovery, e.g. discover optional dependency availability, native code availability. My opinion is that this should be provided by package managers (e.g. opam provides that).
• Package builder, maps build environments to build artefacts and build artefacts to install locations (e.g. topkg + opam-installer)

I tried to explain that philosophy a little bit more in this message. This may not be applicable to every package out there, but I bet that the vast majority can be perfectly well-served by having this clear separation of concerns. The great advantage, as a package developer/maintainer, is that you save a lot of time by delegating the right bits to the entities that should actually be charge while simplifying the overall system for everybody.

[hhugo]

I've just updated the corresponding oasis PR (#60)

[dbuenzli]

Btw. why did you commit this file ? This should be generated dynamically by build.ml.

[hhugo]

It should be removed