From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id AA4EDBC37 for ; Thu, 12 Nov 2009 14:36:06 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcBAI6e+0rRVdzjkGdsb2JhbACCIy+ReocQPwEBAQEJCQwHEwOwfwEFjwcBBoQ8gXCGOw X-IronPort-AV: E=Sophos;i="4.44,727,1249250400"; d="scan'208";a="50222010" Received: from mail-fx0-f227.google.com ([209.85.220.227]) by mail4-smtp-sop.national.inria.fr with ESMTP; 12 Nov 2009 14:35:36 +0100 Received: by fxm27 with SMTP id 27so2356023fxm.3 for ; Thu, 12 Nov 2009 05:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QqS7ZfjPduJ0JCB27y/Ihy7+YDZLvCqeAiyg7zqQdAU=; b=MKPzWnCs8Bbtu1WW/F2N1CWvOKZFcAAxwwgtoQ7QdZW1C5RzzTQRMuWO/YUVxB72uO zHVY8bI26g42inU9ILTW7yD8SfvakwAEjgT9Cc028FMPmGSpbfxVSOm1qmMQy6u5O7DX oJLDRH8dFiLWii0mIbiYmSL/vnBr3pkSToh3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xssmeW0BvhSe6TxysG377Bp0mw36UMhw7QAEX9uBEEtGyn6fvEj2dgCdfBSRIPFI9b w+x7hRq/eZ37rvqXwVfI5oBVLDKhJcsKsojlVAGJOpHjox6eHV/4ClljW6lgiLGXTru6 8kr3YSb8b6c/C3X6wP9RaG3zaVVu01psVtdoE= MIME-Version: 1.0 Received: by 10.102.201.32 with SMTP id y32mr1271408muf.126.1258032935220; Thu, 12 Nov 2009 05:35:35 -0800 (PST) In-Reply-To: <4AFC0515.5050306@citycable.ch> References: <4AFBFC9E.8010802@citycable.ch> <721f7f5a0911120441h7706cd02ud9b6b993532b88f5@mail.gmail.com> <4AFC0515.5050306@citycable.ch> Date: Thu, 12 Nov 2009 14:35:35 +0100 Message-ID: <721f7f5a0911120535y312f659cw6edaad7512e7cd38@mail.gmail.com> Subject: Re: [Caml-list] Including code from a .cm[ox] into another .cm[ox] From: Philippe Veber To: guillaume.yziquel@citycable.ch Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=0016363b9d9038367b04782c9e66 X-Spam: no; 0.00; cmo:01 findlib:01 camlp:01 -pack:01 cmo:01 toplevel:01 guillaume:01 guillaume:01 findlib:01 pxp:01 toplevel:01 struct:01 submodule:01 camlp:01 -pack:01 --0016363b9d9038367b04782c9e66 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You're right this is a linking issue and now the question is at which level you want to "link" your code. I do not see the point of including a cmo in another like you describe : i believe there are simpler and mainstream options. Maybe I miss some details about your problem ? Using findlib to help the linker is one way to do it, but if you insist on loading a single module then you have two other options : - code inclusion -> m4, camlmix, camlp4 or any preprocessor (not that ugly, but still) - the -pack option for combining several cmo in a single one (but then all your modules are included in a "toplevel" module) sorry if i still didn't get your problem ;o). ph. 2009/11/12 Guillaume Yziquel > Philippe Veber a =E9crit : > > Hi >> >> maybe you can have a look at findlib and its #require statement. For >> instance, pxp (xml related library) depends on many cma, but everything >> loads automagically when invoking #require : >> > > No, no, no... this is not the issue at all. My issue is not about loading > stuff with findlib, it's about including a .cmo into another .cmo. I'd li= ke > to create a .cma with only a.ml, and not containing b.ml. > > It's not a toplevel issue, but a 'linking' issue. > > Thanks anyway. > > Guillaume. > > > > > 2009/11/12 Guillaume Yziquel >> >> Hello. >>> >>> Imagine I have a file named a.ml containing >>> >>> module C =3D struct >>> >>>> include B >>>> end >>>> >>>> and a file named b.ml containing the code >>> >>> let f x =3D x + 1 >>> When I compile everything to .cmo files, I cannot load a.cmo from the >>> toplevel without loading b.cmo beforehand. >>> >>> Is there a way to make the 'include B' statement to include the code of >>> the >>> B module in the C submodule directly so that it is not required to load >>> the >>> b.cmo file before loading the a.cmo file? >>> >>> That would be extremely useful to me... >>> >>> All the best, >>> >>> -- >>> Guillaume Yziquel >>> http://yziquel.homelinux.org/ >>> >> --0016363b9d9038367b04782c9e66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You're right this is a linking issue and now the question is at which l= evel you want to "link" your code. I do not see the point of incl= uding a cmo in another like you describe : i believe there are simpler and = mainstream options. Maybe I miss some details about your problem ? Using fi= ndlib to help the linker is one way to do it, but if you insist on loading = a single module then you have two other options :
- code inclusion -> m4, camlmix, camlp4 or any preprocessor (not that ug= ly, but still)
- the -pack option for combining several cmo in a single = one (but then all your modules are included in a "toplevel" modul= e)
sorry if i still didn't get your problem ;o).
ph.



2009/11/12 Guillaume Yziquel <= guillaume.yziquel@citycab= le.ch>
Philippe Veber a = =E9crit :

Hi

maybe you can have a look at findlib and its #require statement. For
instance, pxp (xml related library) depends on many cma, but everything
loads automagically when invoking #require :

No, no, no... this is not the issue at all. My issue is not about loading s= tuff with findlib, it's about including a .cmo into another .cmo. I'= ;d like to create a .cma with only a.ml, and not containing b.= ml.

It's not a toplevel issue, but a 'linking' issue.

Thanks anyway.

Guillaume.




2009/11/12 Guillaume Yziquel <guillaume.yziquel@citycable.ch>

Hello.

Imagine I have a file named a.ml<= /a> containing

=A0module C =3D struct
=A0include B
end

and a file named b.ml contain= ing the code

=A0let f x =3D x + 1
When I compile everything to .cmo files, I cannot load a.cmo from the
toplevel without loading b.cmo beforehand.

Is there a way to make the 'include B' statement to include the cod= e of the
B module in the C submodule directly so that it is not required to load the=
b.cmo file before loading the a.cmo file?

That would be extremely useful to me...

All the best,

--
=A0 =A0Guillaume Yziquel
http://yziquel.= homelinux.org/

--0016363b9d9038367b04782c9e66--