From: Edgar Friendly <thelema314@gmail.com>
To: Arnaud Spiwack <aspiwack@lix.polytechnique.fr>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Package installation assumptions made by odb
Date: Mon, 13 Feb 2012 08:04:23 -0500 [thread overview]
Message-ID: <4F390A57.2020209@gmail.com> (raw)
In-Reply-To: <CAMoPVjfAhRwzY_MUpLOqUGwbg02J5XKJR4=KtW8vTRnqgq+HEA@mail.gmail.com>
On 02/13/2012 06:01 AM, Arnaud Spiwack wrote:
> I see an immediate problem with packages that install several executable
> files (for instance, Melt provides a library and a collection of tools,
> none of them named melt, by the way). I haven't spent time looking more
> than superficially into oasis or odb yet, but it strikes me as a
> possibly important limitation.
>
It looks like the executable is now named melt-build. In this case, odb
would expect the melt project name to be "melt-build" so that its simple
logic can detect if melt is already installed. This does not have any
affect beyond changing the name that must be typed on the command line
to install melt (`odb melt-build` instead of `odb melt`), and the name
for dependencies by other projects (projects depending on melt would
have to specify `dep=melt-build` instead of `dep=melt`).
Also, if melt installs an ocamlfind library named melt, then its odb
package name could be melt or melt-build, depending on which part of
melt should be used to detect its installation. At the moment, odb
doesn't really do version handling (mainly because it's difficult to get
a version number from an executable), although this is a weakness where
odb might improve.
This assumption of executables and libraries being named the same as the
package isn't critical to the design of odb, it's just a simplifying
assumption that works quite well (and would work for melt up to the last
version when its executable was renamed). If there's good reason to
have more complex installed-program detection, this is easily doable,
but the workarounds are simple enough at the moment that this doesn't
seem to be a problem.
E.
next prev parent reply other threads:[~2012-02-13 13:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-11 21:10 Edgar Friendly
2012-02-13 11:01 ` Arnaud Spiwack
2012-02-13 13:04 ` Edgar Friendly [this message]
2012-02-13 13:39 ` Romain Bardou
2012-02-13 13:46 ` Török Edwin
2012-02-13 13:53 ` Edgar Friendly
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=4F390A57.2020209@gmail.com \
--to=thelema314@gmail.com \
--cc=aspiwack@lix.polytechnique.fr \
--cc=caml-list@inria.fr \
/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