Proposal ocaml guidelines

Hans de Goede j.w.r.degoede at
Fri May 4 05:14:14 UTC 2007

Toshio Kuratomi wrote:
> On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote:
>> Okay,
>> The proposal I mailed to the list yesterday is now available here:
> Thanks Hans!

Please keep in mind I'm not an ocaml expert, I just did some reading on it
as I needed to know something about it todo reviews.

> I have a question about bytecode/native code.  Should the guidelines
> specify that module packages build both bytecode and native code?  As a
> precedent, a java library will install a native code version to
> %{_libdir}/ and byte code to /usr/share/java/foo-1.0.jar.

Thats not how ocaml handles things. Ocaml code gets compiled to bytecode 
objects, native<->ocaml glue code gets compiled to native objects.

Then when compiling an application / program, you can compile it in 2 ways:
1) to a bytecode program which will require the ocaml runtime and the .so
    versions of any native code from used modules/libs. All bytecode objects
    from used modules will get staticly liked in.

    This reminds me, since ocaml will dlopen the .so files with native code of
    used modules, an application compiled this way should have Requires:
    for all used modules of which native parts are used.

2) To native code, in this case the bytecode parts of used modules get
    converted to native code and any native objects which are part of modules
    get staticly linked in, resulting in a native binary which is independent of
    any ocaml modules (but which will still depend upon any be dynamicly linked
    against any normal native libraries used by modules, like libjpeg)

> I also wonder if we want to specify that ocaml programs should be
> compiled to native code.

According to Debian's guidelines this has both advantages and disadvantages, so 
its probably best to use upstream's default behaviour.

Also worth noticing is that native compilation is not available on all 
platforms. Luckily it is available for all platforms which are part of Fedora.




What do you think about the Naming part of the proposal? I'm currently doing an 
ocaml related review which mainly needs a "decision" on the naming part of the 
proposal. I think this is not very controversial, so if atleast an agreement 
could be reached on this, then said review can move forward.

More information about the fedora-devel-list mailing list