From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 341067F734 for ; Tue, 22 Sep 2015 21:02:46 +0200 (CEST) IronPort-PHdr: 9a23:9vROSxC0P/I5vMONOx8lUyQJP3N1i/DPJgcQr6AfoPdwSP7ypsbcNUDSrc9gkEXOFd2CrakU16yK6+u5AzdIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/ni6buo9aKOV4ArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6g73EGU2gS2iFDAwXf4QuyCpj4uDH7u+47wyKaMNf7V5g7XD2j6+FgTxq+2wkdMDts1WjNls12xI5WhR+loxs3l4vdep2UMvZze67ZedQySm9IX8IXXCtEVNDvJ7ATBvYMaL4L57L2oEED+F7nXVGh Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=martindemello@gmail.com; spf=Pass smtp.mailfrom=martindemello@gmail.com; spf=None smtp.helo=postmaster@mail-vk0-f52.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of martindemello@gmail.com) identity=pra; client-ip=209.85.213.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martindemello@gmail.com"; x-sender="martindemello@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of martindemello@gmail.com designates 209.85.213.52 as permitted sender) identity=mailfrom; client-ip=209.85.213.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martindemello@gmail.com"; x-sender="martindemello@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vk0-f52.google.com) identity=helo; client-ip=209.85.213.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="martindemello@gmail.com"; x-sender="postmaster@mail-vk0-f52.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAQBUpAFWmzTVVdFdhFIPBr1UAQ2HcwKBQwc4FAEBAQEBAQEBEAEBAQEBBgsLCSEugh2CBwEBAQMBEhEdARsdAQMBCwYFCw0qAgIhAQERAQUBHAYTIod2AQMKCKkrgTA+MYtGgWyCeYl6ChknDVaECgEBAQEBAQQBAQEBAQEBFQEFDoZlhH2CUII9B4JpgUMFjXKHdYsagW+BTpIUg1SCIRIjgRcfAQGCRoIdHjOJbQEBAQ X-IPAS-Result: A0AgAQBUpAFWmzTVVdFdhFIPBr1UAQ2HcwKBQwc4FAEBAQEBAQEBEAEBAQEBBgsLCSEugh2CBwEBAQMBEhEdARsdAQMBCwYFCw0qAgIhAQERAQUBHAYTIod2AQMKCKkrgTA+MYtGgWyCeYl6ChknDVaECgEBAQEBAQQBAQEBAQEBFQEFDoZlhH2CUII9B4JpgUMFjXKHdYsagW+BTpIUg1SCIRIjgRcfAQGCRoIdHjOJbQEBAQ X-IronPort-AV: E=Sophos;i="5.17,574,1437429600"; d="scan'208";a="148249616" Received: from mail-vk0-f52.google.com ([209.85.213.52]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Sep 2015 21:02:44 +0200 Received: by vkfp126 with SMTP id p126so13064533vkf.3 for ; Tue, 22 Sep 2015 12:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EqPi7z171r/a3MW8Hvzs2bQY4lYn6A9UBulTZWZPKPQ=; b=zLDGHYwBFQSbBhbt2BIYogLeRj3/jXkw09gH932dpROERccJssF1RS1jFr1DvwwL37 0XAdJnOi7BpTSQvp09CjA1trb24NNbcOmS3t+FILMPyTRlo0ZPFQn2i2zaVHrInBA0ZA bkXmlq5QevNDgbRFMv6w/TOgsAZJCN7hSlvSxsdPZHa03XKpehyorR/Bx6UAa4kbZsWm gibNdJhP+JsNV2yexOAL7ayKBXLgJmrK4kVmw3EGoAwNqX3VM3KZ4zOLycoCGCtYpAck HJ18QzFEw3aSjfF3fBkgaYu/cBm/v7w/DhyXKpPSn6dgyBOKMrDtG0rIBUNMlJs300I2 i5wA== MIME-Version: 1.0 X-Received: by 10.31.146.203 with SMTP id u194mr19227558vkd.42.1442948563330; Tue, 22 Sep 2015 12:02:43 -0700 (PDT) Received: by 10.103.51.142 with HTTP; Tue, 22 Sep 2015 12:02:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Sep 2015 12:02:43 -0700 Message-ID: From: Martin DeMello To: Gabriel Scherer Cc: OCaml List Content-Type: multipart/alternative; boundary=001a1143945c8beed505205aa497 Subject: Re: [Caml-list] building and using a library in a subdirectory --001a1143945c8beed505205aa497 Content-Type: text/plain; charset=UTF-8 Okay, thanks, that does make sense. I'm curious now as to what the use case is for a .mllib file that just defines an internal library. It doesn't seem to be buying me anything if I don't want to compile the library separately and use it in a different project. martin On Tue, Sep 22, 2015 at 12:45 AM, Gabriel Scherer wrote: > The compiler allows to store C compilation flags in library archives, > but not OCaml-level flags, and in any case that would be a dubious > idea as hardcoding the path to the ocamlfind packages on your system > would make the (bytecode) archive libraries less portable. > > You can easily define the packages of the final executable in several > steps, one per plugin: > > or : package(foo) > ... > or : package(bar) > > Finally, you could also distribute each of your plugin as a separate > ocamlfind package (allowing to combine both the link to the archive(s) > and information about ocamlfind dependencies in a single place, the > package's META file), but that requires re-installing a package for > its changes to be visible from the main program -- so it is probably > more useful for libraries that are less tightly coupled. > > On Tue, Sep 22, 2015 at 9:09 AM, Martin DeMello > wrote: > > On Mon, Sep 21, 2015 at 11:58 PM, Gabriel Scherer > > wrote: > >> > >> > I don't (yet) need dynamic linking; my current main aim with the > .mllib > >> > setup is to specify the package dependencies for each plugin in its > > own > >> > section of the _tags file, and not have a long list of every plugin's > >> > dependencies in the main module. > >> > >> Well, that doesn't quite work: you need to have the ocamlfind packages > >> passed to the command linking the final executable. > >> > >> I suppose changing > >> <**/puz.*>: ... > >> to > >> <**/puz.*> or : ... > >> could work, as this line seems to pass all the libraries flags. > > > > > > Isn't there any way with a .cmxa to compile the dependencies into a > library > > and then just have the library as a link-time dependency for the main > > project? I can imagine things getting pretty messy once I have several > > plugins and have to concatenate all their package deps into the file.* > tags > > line. > > > > martin > --001a1143945c8beed505205aa497 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay, thanks, that does make sense. I'm curious now as= to what the use case is for a .mllib file that just defines an internal li= brary. It doesn't seem to be buying me anything if I don't want to = compile the library separately and use it in a different project.

<= /div>
martin

On Tue, Sep 22, 2015 at 12:45 AM, Gabriel Scherer <gabr= iel.scherer@gmail.com> wrote:
The compiler allows to store C compilation flags in library archives,
but not OCaml-level flags, and in any case that would be a dubious
idea as hardcoding the path to the ocamlfind packages on your system
would make the (bytecode) archive libraries less portable.

You can easily define the packages of the final executable in several
steps, one per plugin:

=C2=A0 <plugin1/**> or <main.*>: package(foo)
=C2=A0 ...
=C2=A0 <plugin2/**> or <main.*>: package(bar)

Finally, you could also distribute each of your plugin as a separate
ocamlfind package (allowing to combine both the link to the archive(s)
and information about ocamlfind dependencies in a single place, the
package's META file), but that requires re-installing a package for
its changes to be visible from the main program -- so it is probably
more useful for libraries that are less tightly coupled.

On Tue, Sep 22, 2015 at 9:09 AM, Martin DeMello <martindemello@gmail.com> wrote:
> On Mon, Sep 21, 2015 at 11:58 PM, Gabriel Scherer
> <gabriel.scherer@gmail= .com> wrote:
>>
>> > I don't (yet) need dynamic linking; my current main aim w= ith the .mllib
>> > setup is to specify the package dependencies for each plugin = in its > own
>> > section of the _tags file, and not have a long list of every = plugin's
>> > dependencies in the main module.
>>
>> Well, that doesn't quite work: you need to have the ocamlfind = packages
>> passed to the command linking the final executable.
>>
>> I suppose changing
>>=C2=A0 =C2=A0<**/puz.*>: ...
>> to
>>=C2=A0 =C2=A0<**/puz.*> or <file.*>: ...
>> could work, as this line seems to pass all the libraries flags.
>
>
> Isn't there any way with a .cmxa to compile the dependencies into = a library
> and then just have the library as a link-time dependency for the main<= br> > project? I can imagine things getting pretty messy once I have several=
> plugins and have to concatenate all their package deps into the file.*= tags
> line.
>
> martin

--001a1143945c8beed505205aa497--