[CMake] CMake & OCaml

Alan W. Irwin irwin at beluga.phys.uvic.ca
Wed Aug 25 19:57:01 EDT 2010


Hi Eric:

On 2010-08-25 22:20+0200 Eric Noulard wrote:

> [...]My ideas was that some languages:
>    - OCaml   (ocamlbuild)
>    - ADA      (gnatmake)
>    - may Java too (ant/maven)
>
> have already very efficient build tool with some history of usage too.
> I don't know many Java developers who speaks "makefile", most
> of them speak "Eclipse/Netbeans" and many of them ant (http://ant.apache.org/)
> what would be the advantage to go for CMake?

Good point.  Of course, these language-specific build tools are in a
different category than general build tools such as make, nmake, etc.
that warrent their own generators.

>
> Most of those tools are already cross-platform and they are pretty
> efficient (Ant for example is very handy and includes a plugins system
> which makes it easy to extend for doing fancy things)
> with a good user base.

To provide some background information, gnatmake is provided as part
of the gcc Ada compiler, and I know gnatmake already works on Linux
and Mac OS X. There is good potential for it to work on Windows
because MinGW-4.5.0 includes the gcc Ada compiler, but PLplot
developers havn't tested the CMake Ada language support on
MinGW/Windows yet. Currently, I don't know any other potentially
cross-platform tools to build Ada software, but I haven't looked very
hard for those since I completely concentrated on gnatmake when
implementing CMake language support for Ada.

I have no experience with ocamlbuild other than on Linux, but a
superficial google search indicates that people have been using it on
Windows so I guess we can claim it is cross-platform.  As far as I am
aware, our current detailed OCaml build for the bindings and examples
has only been tested on Linux, but since ocamlbuild uses these
detailed commands itself, it is probable this can be a true
cross-platform approach as well.  I may get a chance to test our
current detailed command approacn on wine shortly.

> [...] CMake should know about
>   sources (directories and files)
>   dependencies
>   targets
>
> I may do something like:
>
> find_delegate_builtool(Ant)
>
> if (Ant_TOOL_FOUND)
>   add_delegated_target(TARGETS JavaPlug1 JavaPlug2
>                                   SOURCES  jsrc1 jsrc2 build1.xml build2.xml
>                                   BUILD_COMMAND ${Ant_TOOL} all
>                                   CHECKDEP_COMMAND ${Ant_TOOL} all
>                                   CLEAN_COMMAND ${Ant_TOOL} clean
>                                   GETOUTPUTS_COMMAND ${Ant_TOOL} getoutput)
> endif(Ant_TOOL_FOUND)
>
> the "delegate build tool" would be responsible for building targets
> with "BUILD_COMMAND" and "CHECKDEP_COMMAND" for checking dependencies
> SOURCES specifies the list of sources (inputs for the BUIDL TOOL).
> "GETOUTPUTS_COMMAND" may be used by CMake to get the list
> of may be file/dir produced by the build tool.
> the "CLEAN_COMMAND" may be used to clean that part of the project.

Instead of creating an additional cmake command, I think a better
approach would be to extend the existing CMake language support
infrastructure so that it should be possible to choose Ant as one of
the "compilers/linkers" supported for the Java language.  Then
add_library and add_executable would "just work" for "Antified"
projects.  And similarly for other projects that might prefer non-Ant
build tools for java.

That language support infrastructure generalization should include the
possibility that library and executable builds can be done with more
than one command.  And have some way of controlling dependencies and
file cleaning for all files generated by those commands.  I believe
that would be sufficient in the OCaml case (whether using a detailed
build or using ocamlbuild) and also the Ada case (whether using a
detailed build or gnatmake).  From what you say above, it looks
possible that such a generalization would be sufficient in the Ant
case as well.

I should also say that my ideas are to help generate discussion and
food for thought but should have "double quotes" around them (as you
say) because I am not familiar with how the language support
infrastructure is implemented at the C++ level of the CMake code, and
I don't feel I have a really good overview of all the many different
Ada, OCaml, and Java build tools out there.  The fundamental principle
should be that CMake's language support infrastructure is generalized
well enough so that the user's choice of build tool for a particular
language is not limited by some C++-level language-support restriction
under CMake.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list