On Tue, 8 Sep 2015 20:02:08 +0100 "Richard W.M. Jones" rjones@redhat.com wrote:

OCaml is a statically-safe programming language derived from ML which compiles to very fast native code. It contains native code backends for most architectures (all Fedora primary & secondary arches except s/390x in fact).

the s390x situation is expected to change in the future :-)

Currently Fedora downstream carries two non-upstream backends: For ppc64 (big endian), a backend was written many years ago by David Woodhouse and was upstream for a time, but was dropped when the PlayStation 3 stopped supporting Linux. For ppc64le (little endian / POWER8) IBM's Michel Normand contributed a native code backend last year. The upstream project always carried a ppc (32 bit) backend, but we didn't use it and it's not very interesting for us.

https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02

Red Hat and IBM have provided help and loaned equipment to the upstream project, and as a result upstream have now added ppc64 and ppc64le backends. This work was merged at the end of August. These backends were inspired by the Red Hat & IBM work but are not derivatives. For details see:

https://github.com/ocaml/ocaml/pull/225

So what I want to do is add the new backends [actually it's a single, combined and extended ppc/ppc64/ppc64le backend] to Fedora Rawhide, and drop our non-upstream backends.

I have so far cherry-picked the merge commit on top of our Fedora OCaml tree, and I have dropped the downstream ppc64/ppc64le commits from our tree. (This is not pushed yet so doesn't appear in the git.fedorahosted.org link above.)

I have tested it on ppc64le to check that the compiler compiles itself. A scratch build of the compiler with the new backend is here (I reserve the right to make further changes, this is just a preliminary test build):

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2741551

I used this to compile some ocaml-* packages on ppc64le, with -- it has to be said -- mixed results. There are two compiler bugs revealed. This compiler won't be able to compile all the ocaml-* packages on POWER. However because of the depth of dependencies, I cannot easily do scratch builds to find out which packages will be broken.

Hence I'd like to do a full rebuild, again, to see what breaks. This *shouldn't affect primary architectures at all*, but will probably leave some broken ocaml-* packages on the ppc64/ppc64le secondary arches.

We've actually done two complete rebuilds during the F24 development cycle already, which in a way is good because it means I know how long it should take, and I'm confident that the scripts I use will work again:

http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml;h=13a8c...

So I'm pretty confident the primary arch rebuild will go fine, since it's not affected by any of the above changes - it's basically just a release bump. We don't even need to use a side tag for this because the "old" and "new" packages can be mixed on x86 - they are the same.

The plan for ppc64/ppc64le would then be to fix the bugs revealed in the rebuild with upstream help.

Any comments?

Moving to upstream code generator is definitely a good thing, having some broken ocaml-* packages for a limited period of time, until the compiler is fixed, is acceptable. My only concern is about the various virt related tools that are written in OCaml and are needed during the release engineering tasks.

Dan