move ocamlbuild to its own repository.

[vicuna]

Original bug ID: 6402
Reporter: @hhugo
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2017-09-24T15:31:50Z)
Resolution: fixed
Priority: normal
Severity: feature
Fixed in version: 4.03.0+dev / +beta1
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Monitored by: @gasche @ygrek @jmeber @hcarty @dbuenzli gildor

Bug description

• so releases are not necessary mapped to OCaml's one
• so improvement can benefit build with other OCaml version

[vicuna]

Comment author: gildor

I think this will be an overall improvement:

• hopefully benefit from external users contribution
• allow to fix rules outside of OCaml release cycle

+1

[vicuna]

Comment author: jpdeplaix

I also think it would be a good thing to do.

Some times ago, this idea of spliting the tools which are in the distribution was raised and I wasn't sure whenever it was a good idea or not for ocamlbuild. My main con, was that I think that one reason why ocamlbuild is used is that it's distributed with ocaml.

But now, after thinking of it a little bit more, I think this con can be erased by « massive » contributions and a shorter release cycle.

I tried to do the split last week but I didn't had the time to finish it.

[vicuna]

Comment author: @hhugo

https://github.com/hhugo/ocamlbuild

[vicuna]

Comment author: gildor

It should be in https://github.com/ocaml/ocamlbuild...

Maybe contact Anil or Fabrice Lefessan about that.

[vicuna]

Comment author: gildor

Also, if you get approval for the move to github/ocaml/, I am willing to spend five minute to transfer it.

[vicuna]

Comment author: @hhugo

I can already change the github repo owner to the ocaml organisation

[vicuna]

Comment author: gildor

hhugo, but there will be some conflict if you do so! Please contact Anil/Fabrice before.

[vicuna]

Comment author: @avsm

Glad to see you working on this! It would be best to leave it as a private fork until there is agreement from the development team that this is a direction we want a future release of OCaml to go in.

OCaml 4.02 is in feature freeze right now in preparation for branching for release, so it would probably be best to bring this up in a week or so after that branch has been created, and trunk is 4.03dev.

[vicuna]

Comment author: @hhugo

Thanks for the details.

I've just synced the repo with the latest trunk (with "safe-string" reverted to build on 4.01). gildor, jpdeplaix, you now both have access to this repo if you wish to contribute

[vicuna]

Comment author: gildor

Draft of TODO goals:
https://github.com/hhugo/ocamlbuild/wiki

If you want I can setup a forge project for mailing list/tarballs/homepage...

[vicuna]

Comment author: @avsm

Please don't do that until there's consensus from the core team, as otherwise it'll be forking confusion as things get out of sync.

[vicuna]

Comment author: gildor

ACK, I don't play against the core team. I suppose hhugo will agree that if the core team is opposed to this decision we will just withdraw the ocamlbuild git repository and that will be the end of the story.

[vicuna]

Comment author: berke.durak

Not sure about this; I think it's a good thing that a proper build tool ships with Ocaml itself. If you move it to its own repo, people will inevitably want to use this or that external module, and you can't ship that with the compiler.

I seem to recall that I had to write Ocamlbuild's glob module in pure Ocaml to avoid a dependency on Str. And Nicolas wrote a My_unix module so that Ocamlbuild would work even with "degraded" Unix environments.

On the other hand it is true that the plugin/rule/tag system is difficult to use.

Why not fork Ocaml, work on Ocamlbuild, and use pull requests on Github?

[vicuna]

Comment author: gildor

I think ocamlbuild is a quite separate project and easily splitable. Given the fact that you don't use ocamlbuild inside OCaml sources that a good candidate to be moved away.

If you have a different project, you'll be able to follow a different release cycle (shorter hopefully).

E.g. fix the .cmxs rule and release rather than wait for all other patches on all other topics to be merged.

Given the fact that camlp4 and tk lib has been moved to their own project, I didn't think it was a problem.

On the topic of using external module and rewriting code like "glob" or "my_unix", I don't share your opinion... I would use Str and Unix and if mandatory I would enforce thing like depending on findlib. I don't have enough time to redo everything.

[vicuna]

Comment author: @gasche

The main problem is that there are currently extremely few people remotely motivated to contribute to ocamlbuild's development. I count two, jpdeplaix and myself. That remains a problem whether or not ocamlbuild is split.

It's very good to be able to make releases independently of OCaml's release schedule. But on how many occasion would it have made sense, between the 4.01 and the 4.02 release? Answer: zero times. Nobody gave a damn about helping with ocamlbuild development (except jpdeplaix above) since the 4.01 release, so there was nothing to release.

Will having ocamlbuild in its own github repository encourage people to contribute? Well:

• ocaml already has a github repository, and we even monitor pull requests now, where would the added convenience be?
• camlp4 has been split into a separate github repository just before 4.01. How does being split as its own github work for camlp4? Besides Jérémie Dimino's maintenance work, there have been precisely four external contributions, three of them coming from regular contributors to the OCaml distribution itself. I can't see a wave of new contributors here.

(I also have a draft of improved OCamlbuild documentation, publicly announced 8 months ago, with a github repository. So far, besides one batch of typo fixes, no substantial contribution.)

I feel neutral about splitting ocamlbuild as a separate project: I see no reason why that would make any difference -- besides making "which build system to use?" discussions even funnier.