Re: [Caml-list] ocaml support in autotools

[Guillaume Rousse <Guillaume.Rousse@inria.fr>]

Dmitri Boulytchev 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.

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.

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, ...).
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France