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.
It seems the most advanced work from all I've been suggested to look at,
so I used it as a work base. I'd have some questions however about
desirable behaviour for those macros.

First, I'd like to keep interfaces and behaviour as close as possible
from standard autoconf macros, in particular avoid taking any decision
in the macro themselves. Very few of them, for example, throw an error
if test fails, they either set variable or takes an action as argument,
so as to let the programmer decides what to do.

So, I'd like to avoid any use of AC_MSG_ERROR or AC_MSG_WARN in those
macros, only AC_MSG_RESULT for printing information. The use of
action-if-not-found argument in macro checking for several programs is
also unpractical, as its exact semantic is quite fuzzy (what if one of
them but not the others are found ?). So, those macros should only set
useful variables, without side effect.

They are exceptions, tough, for compiler macros-related macros, such as
AC_PROG_CC and AC_PROG_CPP. I guess this is because they are unlikely to
get used in conditional context. So I guess it would be quite reasonable
to make AC_PROG_OCAML fails if no working ocaml is found. And probably
also AC_PROG_CAMLP4. But definitevely not for others, and particulary
for macros macros looking for ocamllex or ocamlyacc: in C world, lex and
yacc-generated sources are generally distributed, to make lex and yacc
use non mandatory on installation platforms, and as a consequence,
AC_PROG_LEX and AC_PROG_YACC are not fatal macros.

So my current opinion is:
- have AC_PROG_OCAML fails if ocamlc is not found
- have AC_PROG_CAMLP4 fails if ocamlp4 is not found
- have all other macros never fail

Second, what to do with optimised versions ? It is desirable for the
user or the developer to be able to select between optimised and
non-optimised version of a given tool ?

If not, having a single variable for each tool, silently defined to the
optimised version if available and usable, would be the best option.
OCAMLC would then correspond to ocamlc.opt or ocamlc

If yes, a combination of user options (through AC_ARG_ENABLE),
developper options (conditional macros arguments), or distinct variables
(OCAMLC and OCAMLC_OPT) would do the trick.

Third, I'd like some standard macro to allow the user to select if he
wants bytcode compilation, native compilation, or both, the same as you
have when using libtool for producing either static or dynamic
libraries. Does it makes senses to add those switches to AC_PROG_OCAML,
and to define additional variables, such as OCAML_WANT_BYTECODE and
OCAML_WANT_NATIVE ?

Fourth, in the AC_PROG_FINDLIB, there is a switch allowing the user to
disallow the use of ocamlfind, even if present on the system. Why is
thie behaviour desirable ?

BTW, my global ocaml knwoledge is quite slim, so I may miss details :)
-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France