Caml Support for Automake

[Tom Murray]

Greetings--

I've been working on a patch to automake to provide support for Caml, 
currently the Ocaml compilers. Attached is the first reasonably working 
version.

Features include compilation of programs and libraries, possibly with 
mixed Caml and C code, automatic dependency generation, and both 
bytecode and native code compilation. I added a section to the .texi 
file with more complete information.

Since this is my first time hacking automake or even looking at its 
internals, I'd like to mention a few less than aesthetically pleasing 
:-) things I had to do, and ask the list for comments and suggestions.

The first issue I had was that Caml compilation differs from languages 
already supported by automake. The output (in the case of a program), 
looks just like a C program, and so handle_source_transform() kept on 
wanting to treat the .ml source files like C/C++, ObjC, etc. source 
files, transforming foo.ml to foo.$(OBJEXT). My solution was to add 
support in handle_single_transform_list() for a third return value from 
the lang_XXX_rewrite. This last value specifies the extension for the 
output object, so Caml $(OBJECT) gets overwritten to .cmo or .cmx. Your 
thoughts on this?

Another complication was that, even if a Caml program contains a .c 
file in its sources, the linker needs to be the Caml compiler. I tried 
shoving this behavior into _PROGRAMS, but in the end I felt that adding 
_MLPROGRAMS and _MLLIBRARIES primaries was cleaner.

But the ugliest thing of all was handling native code compilation. For 
those not familiar with OCaml, there is a highly portable bytecode 
format, and on many platforms an efficient native code compiler whose 
performance can rival that of C++. There are separate compilers, 
separate file suffixes for objects and libraries, etc. One convention 
in OCaml packages with hand-built make files is to have "make all" 
build the bytecode and "make opt" build the native code. Native code 
programs are built with a '.opt' extension on Unix platforms (I don't 
know about Win32).

Anyway, I wanted the above behavior, but without forcing the user to 
specify both compilation versions. A bit nasty, but I settled on the 
following solution: Define two languages, "caml" and "camlopt", to do 
all the usual language stuff. In handling MLPROGRAMS and MLLIBRARIES, I 
first process the bytecode and then, before processing native code, I 
toggle the extension map to have .ml point to the "camlopt" language. 
After that's done, I toggle it back to "caml". In addition, I register 
a fake .mlx extension to trick handle_languages() into processing the 
"camlopt" language at the end. Finally, I make an "opt" target present 
in all makefiles if the package use Caml, so that "make opt" can 
recurse (opt-recursive) to subdirectories containing the code.

Sorry for the long note. Your suggestions are very welcome.

Thanks,

tm


P.S. The patch is for 1.7.8, will try to update to 1.7.9 soon.

automake-1.7.8-p4caml.patch.gz
Description: GNU Zip compressed data