From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Martin DeMello <martindemello@gmail.com>
Cc: OCaml List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] building and using a library in a subdirectory
Date: Tue, 22 Sep 2015 09:45:38 +0200 [thread overview]
Message-ID: <CAPFanBE+ywOaKVGd_B5M4e5mL4dXwuRneDg7gpd9s8KjzNyr=w@mail.gmail.com> (raw)
In-Reply-To: <CAFrFfuG+eOPdNncogzZZ8YTRKMgTEgn5JXd8LgMH501axXgq=g@mail.gmail.com>
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:
<plugin1/**> or <main.*>: package(foo)
...
<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 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 <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
> 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
next prev parent reply other threads:[~2015-09-22 7:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 6:23 Martin DeMello
2015-09-22 6:45 ` Gabriel Scherer
2015-09-22 6:52 ` Martin DeMello
2015-09-22 6:58 ` Gabriel Scherer
2015-09-22 7:09 ` Martin DeMello
2015-09-22 7:45 ` Gabriel Scherer [this message]
2015-09-22 19:02 ` Martin DeMello
2015-09-22 19:22 ` Christian Lindig
2015-09-22 6:46 ` Martin DeMello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPFanBE+ywOaKVGd_B5M4e5mL4dXwuRneDg7gpd9s8KjzNyr=w@mail.gmail.com' \
--to=gabriel.scherer@gmail.com \
--cc=caml-list@yquem.inria.fr \
--cc=martindemello@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox