See also ocaml/ocaml#464.

@whitequark, you are in charge :-)

Sure.

I think we should make a new release of ocamlbuild with this patch. Because currently we can't test the 4.03 branch easily (ex: cryptokit broken). @gasche I though you wrote somewhere the step for a release of ocamlbuild but I can't find where it is.

@bobot thinking about this more, I'm not sure why we need to do a release quickly, though. Can't you just pin ocamlbuild to its master branch while doing your testing?

The reason I ask instead of just releasing is that I expect this situation to happen again in the future: OCaml upstream will change its compilation behaviour in ways that require ocamlbuild changes. I'm not sure we should immediately do a release -- at least if there is an another way to use some "safe with trunk" branch without constantly making releases.

In this specific case, we know this behavior will be as currently in the 4.03 release, and we don't expect other ocaml-side changes to break ocamlbuild, so it makes sense to have a release between now and 4.03 release anyway. So I'm fine with having a release. But I would like you (or someone else) to work out a process to use pinning instead, because in the general case we shouldn't have to release to keep in synch.

But you were agreeing about what I just say.... I can make a merge request
for a readme.md that indicates the exact pin line (I think the usual one).

@whitequark , now that ocaml/ocaml#464 has been merged, do you have any advice on how to handle it on the ocamlbuild side? Given that people may use recent ocamlbuild version but keep using 4.03, we probably can't just revert the revert; I suspect that the easiest way is to leave the code as-is, maybe with a comment there that >=4.04 OCaml version would actually support the -o option, to revisit later when we don't need to support 4.03 anymore.

@gasche It is rather unfortunate, but I agree that there's probably no other way forward.