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.)