From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id DF133BB84 for ; Tue, 13 Jan 2009 21:44:20 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.37,261,1231110000"; d="scan'208";a="22425156" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 13 Jan 2009 21:44:20 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id n0DKiKK6011835 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 13 Jan 2009 21:44:20 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMCAGiLbElQDPIyjWdsb2JhbACUGgEBAQEJCQoJDwW7QIVv X-IronPort-AV: E=Sophos;i="4.37,261,1231110000"; d="scan'208";a="21441673" Received: from smtp23.orange.fr ([80.12.242.50]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Jan 2009 21:44:19 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2348.orange.fr (SMTP Server) with ESMTP id 659A81C00098; Tue, 13 Jan 2009 21:44:19 +0100 (CET) Received: from giga (AVelizy-155-1-95-34.w90-35.abo.wanadoo.fr [90.35.90.34]) by mwinf2348.orange.fr (SMTP Server) with ESMTP id 2BE581C00083; Tue, 13 Jan 2009 21:44:19 +0100 (CET) X-ME-UUID: 20090113204419179.2BE581C00083@mwinf2348.orange.fr Received: from yocto.gallu.homelinux.org ([192.168.2.2]) by giga with smtp (Exim 4.63) (envelope-from ) id 1LMq7V-0000IV-Oq; Tue, 13 Jan 2009 21:44:18 +0100 Received: by yocto.gallu.homelinux.org (sSMTP sendmail emulation); Tue, 13 Jan 2009 21:44:17 +0100 Date: Tue, 13 Jan 2009 21:44:17 +0100 From: Sylvain Le Gall To: Gilles Pirio Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Ocaml back-end Message-ID: <20090113204417.GA11624@yocto.gallu.homelinux.org> References: <605bf2750812060448u787862c9xdc2528cb61bc01d7@mail.gmail.com> <605bf2750901131109n4b86e00eqbe6451d1028156a7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <605bf2750901131109n4b86e00eqbe6451d1028156a7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Miltered: at discorde with ID 496CFD24.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 ocaml:01 ocamlopt:01 ocamlopt:01 dynlink:01 makefile:01 camlp:01 dynlink:01 compilation:01 le-gall:01 bug:01 compiler:01 cmo:01 copt:01 cmo:01 Hello, On Tue, Jan 13, 2009 at 07:09:16PM +0000, Gilles Pirio wrote: > 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. > You can play a little bit with camlp4 and pa_macro to disable certain part of your opt.opt (like replacing dynlink call by nothing/empty list...). I think you can try doing this kind of conditional compilation well enough if your changes are located in an almost central place > On Tue, Dec 9, 2008 at 7:31 PM, Sylvain Le Gall wrote: > > On 09-12-2008, Gilles Pirio 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/ > (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 Regards Sylvain Le Gall