Browse thread
ocaml support in autotools
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-08-04 (01:15) |
From: | Grigory Batalov <bga@t...> |
Subject: | Re: ocaml support in autotools |
On Thu, 03 Aug 2006 17:10:53 +0200 Guillaume Rousse <Guillaume.Rousse@inria.fr> wrote: > > We are currently using a set of autoconf+automake customized scripts to > > configure and build all of our OCaml projects. The scripts are available > > through http://oops.tepkom.ru/projects/template. > And yet another interface question, this time more related to > AC_CHECK_OCAML_MODULE > > Basically, your implementation tries to discover minimal include flags > needed to make a module available, using various strategies: > - no additional flags > - ocamlfind-based additional flags > - developper defined (through additional macro option), user-defined > (through configure option) and confidure-defined (through running > `ocamlc -where`) flags > > This is not really similar to default AC_CHECK_LIB macro, which just > determine if using all currently available flags, searched library is > available or not. Nor to PKG_CHECK_MODULE (closest ocamlfind equivalent > in C world) that just returns flags computed by pkg-config. Well, we often develop several libraries "in place", without installing, so ../project1 ../project2 cross-referrences are widely used. This is why custom paths in AC_CHECK_OCAML_MODULE appeared. > Knowing if an ocmal module is part of core (thus no need for additional > -I flag), or has ocmalfind support can be statically determined, not at > configure run-time. So, I'd better gives AC_CHECK_OCAML_MODULE a > behaviour more similar to AC_CHECK_LIB, and split ocmalfind logic into a > distinct AC_CHECK_OCAMLFIND_MODULE (or any other better name) that would > just set proper variables. Ok, this looks good. > BTW, the macro seems to be misnamed: what you check for actually is a > set of modules (the second argument), not just a single one. I guess you > want to check for something larger, such as lablgtk, which has several > modules, right ? In that case, I'd rather call it > AC_CHECK_OCAML_MODULES, or something else if there is a dedicated word > in OCaml world to call a set of modules distributed together (library in > C word, distribution in Perl world, package, ...). Sure. At the beginning we had just one module to check =), but later expanded macro to several. AC_CHECK_OCAML_PKG (ocamlfind calls them "packages") should be better. What for camplp4 files, there is several types ("parsers", "printers"), but they all probably should be named "extensions", so AC_CHECK_CAMLP4_EXT would be nice. (Correct me, if I'm wrong.)