automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Caml Support for Automake


From: Tom Murray
Subject: Caml Support for Automake
Date: Sun, 21 Dec 2003 19:17:56 -0800

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.


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]