On 02/13/2012 08:39 AM, Romain Bardou wrote:
For instance, I'm currently working on a suite of tools named
like foo-feature1, foo-feature2, foo-feature3 and so on. The package
would obviously be named foo, but it does not make sense to have a
single "foo" executable. It does not make sense to have once package per
executable either.
If it's all compiled at once, it's probably one package - don't split it
up. I see three options:
1) name your package (in odb) foo-feature1 (ugly, but simple and works)
2) provide a dummy executable `foo` for odb to detect
3) convince me that your requirements are common enough to deserve more
complexity in odb
There's no need for odb to detect (or even know about) all three
foo-features, it's perfectly fine for it to only know about one of them
and base its decision to recompile on that one.
So I guess you need some way to override this
behavior when needed. Can odb extract this kind of information from an
_oasis file, or from a META file? I'm not very familiar with those.
odb doesn't directly access either of those files. Oasis-db extracts
lots of info from _oasis files and make them available to odb in a form
it understands. Findlib also handles META files on behalf of odb,
although for different uses.
Regarding Melt, I'm a bit confused: you say in this mail that "its odb
package name could be melt or melt-build, depending on which part of
melt should be used to detect its installation". But in your guidelines
it is written: "Programs that are both should do both". By the way, Melt
actually installs two libraries: Melt and Latex.
At the moment, the library/executable distinction is important only for
detecting installed packages. If a package is a library, it is
installed only if ocamlfind knows of an ocamlfind package with the same
name as the odb package. Similarly, if a package is a executable, it is
installed only if `which` knows of that executable name.
Regarding the version number, if you need to define a standard I think
it would be good if this standard was to call the executable with the
"-version" option. It is, after all, the behavior of "ocamlc". This does
not work for libraries though;
Libraries are not a problem - ocamlfind provides a version for them
trivially (from their META file). IIRC, I wrote some code that tried to
run `foo -version` to get the version of foo, but it looks like I'll
have to parse the output of most programs looking for a version number.
E.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
