Fri Feb 12 14:20:00 GMT 2010
--- On Fri, 2/12/10, Yaakov (Cygwin/X) <firstname.lastname@example.org> wrote:
> From: Yaakov (Cygwin/X) <email@example.com>
> Subject: Re: [ITA] ocaml
> To: firstname.lastname@example.org
> Date: Friday, February 12, 2010, 12:05 AM
> Before we start:
I do not see an option to set yahoo to automaticly wrap, but I can
manually insert new lines.
> On 11/02/2010 15:36, Ed Keith wrote:
> > It has been brought to my attention that the ocaml
> package has been
> > orphaned. I am willing to take it over.
> That's good news! You've chosen a bit of a challenge
> to start off with.
> > I believe I have the source package ready, but am
> still having problems
> > figuring out exactly how to package the bin, I am
> working on it.
> Since you didn't mention ITP'ing flexdll, I take it that
> you build ocaml with only static libraries.
> You may want to take a look at how I built OCaml for Cygwin
> (Yes, that's for 3.11.1; 3.11.2 just came out and I was
> working on other things this week.)
Thanks, I will look at it.
I was going to set up a project on BerliOS, but maybe I should join your
existing project on source forge.
I see you used the GPL, is that kosher? or should you have used the QPL?
I've been trying to figure that out for the request to BerliOS, but was
not sure how to handle it.
> The "official" way of supporting OCaml shared modules
> (dll*.so stublibs and *.cmxs natdynlink modules) on PE/COFF
> platforms is with FlexDLL, which implements a way to link
> libraries without resolving all their symbol dependencies at
> link time. (Ports SVN also includes a few patches
> necessary for flexdll to work correctly.) The drawback
> is that you *must* use the OCaml compilers to link any code
> that uses OCaml, which means, for instance, the GraphViz
> OCaml bindings whose stublib is normally linked with libtool
> cannot be built as-is, nor can Kalzium be built with the
> solver which uses facile (native code) but links with
> CXX. The vast majority of packages build just as they
> do on ELF platforms, so this is a tradeoff to be made for
> the functionality. The only alternative is ugly, won't
> fix .cmxs linkage, and won't be supported upstream, so it's
> probably not worth the bother.
> The other issue to be determined is what should be (in
> cygport terminology) OCAML_LIBDIR. By default, this is
> /usr/lib/ocaml, but some distros version this in order to
> account for the API/ABI changes which do periodically
> occur. (For instance, there was such a change between
> 3.09 and 3.10.0, which they then undid for 3.10.1. I
> suppose I got what I deserved for using a .0 release.)
> Actually, Debian *used* to do this, but today I see that
> they stopped, possibly because it would be quite tedious to
> rebuild ALL ocaml packages for every OCaml point
> release. So sticking with the default may make sense,
> with the understanding that packages may have to
> periodically be rebuilt as time goes on.
> As for packaging, my .cygport creates separate packages for
> ocaml-camlp4 (due to its size and only periodic usage) and
> ocaml-labltk (due to the added dependency on tcl/tk).
> You don't have to go this route, but I will at least suggest
> HTH, and please let us know how we can further help with
> your ITA.
Thank you very much. I'll take you up on this.
>  http://caml.inria.fr/ocaml/release.en.html
>  http://alain.frisch.fr/flexdll.html
>  http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/devel/flexdll/
>  http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/ocaml/ocaml-3.10.2-1.src.patch?revision=4626&pathrev=6920
Thanks for all your advice. I'm still digesting much of it.
More information about the Cygwin-apps