Greetings all..

Following up on an idea explored few weeks ago, I've now implemented the
dynamic back-end mechanism on ocamlopt.

What would be the way to go for ocamlopt.opt? I don't think we want to have
this dynamic back-end thingie with opt.opt as native dynlink isn't supported
on all platforms. My approach at the momemt is to have different files for
the back-end loader (depending on whether it is an opt or opt.opt build). So
the makefile is a bit messier than before. Would that be ok anyway, any
better way to do that that I'm not aware of? If this is fine, I'll submit my
patch.

Cheers
Gilles



On Tue, Dec 9, 2008 at 7:31 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote:

> On 09-12-2008, Gilles Pirio <gilles.pirio@gmail.com> wrote:
> >> To my mind, the best way is to provide a patch through the bug tracking
> >> system of INRIA. This is highly probable that INRIA team doesn't accept
> >> it directly but ask you to justify/modify it in order to fit the whole
> >> compiler -- which could be quiet a long process in fact.
> >
> > It would greatly help to know what the INRIA team would consider as
> > acceptable ahead of doing the work. What kind of guidlines would you
> > advise me to follow? I guess I can add new passes but can I modify
> > existing ones?
> >
> > The ideal solution would be to open the back-end using the dynlink
> > library. I've done it with 3.11 to speed up development. The back-end is
> now
> > a cmo file. I separately compile copt0.cmo, copt1.cmo... with different
> > back-ends. Then I can use command like: ocamlopt -copt copt0.cmo
> myfile.ml
> > to compile with my back-end.
> > But even though that's a small change I'm not sure the INRIA guys would
> > like it, right?
> >
> >
>
> This idea rocks! The best way is to begin by providing a basic patch and
> follow this explanation:
> http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/<http://et.redhat.com/%7Erjones/how-to-supply-code-to-open-source-projects/>
> (even if it is not said, half of the people involved are OCaml
> developers).
>
> The other idea is that the smallest is the best. That's why your idea
> rocks. If the possibility to dynamically load backend is small, it will
> be a very good first step.
>
> When you will have made this first step (that can profit to all), you
> can either submit your backend or provide it by any other mean.
>
> Regards
> Sylvain Le Gall
>
> ps: consider fecthing a copy of the CVS
> http://camlcvs.inria.fr/
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>