Re: ocaml support in autotools

[Grigory Batalov <bga@tepkom.ru>]

On Thu, 03 Aug 2006 14:56:05 +0200
Guillaume Rousse <Guillaume.Rousse@inria.fr> wrote:

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

  Any examples? =)

> 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

  As we do right now.

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

  We use OCAMLCDOTOPT for ocamlc.opt and OCAMLOPTDOTOPT for ocamlopt.opt
  inside AC_PROG_OCAML macro, but they are not available to user yet.

  It seems like optimized tools work faster (?). What if we will prefer
  optimized tools by default, but switch to bytecoded if user gives
  --without-opttools configure argument ?

  BTW, in my distribution ocamlc is a soft link to ocamlc.opt =).

> 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 ?

  Configure options
  --enable-native sets OCAML_BUILD_NATIVE
  --enable-bytecode sets OCAML_BUILD_BYTECODE
  or similar ?

  Optimized objects have different file extension (.cmx instead of .cmo),
  so it is quite easy to define another build rule in Makefile.

> 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 ?

  I guess, we have found a broken findlib on some platform and desided
  to optionally disable it.

> BTW, my global ocaml knwoledge is quite slim, so I may miss details :)