Re: [Caml-list] About ocamlbuild

[Xavier Clerc <xavier.clerc@inria.fr>]

----- Mail original -----
> Hi,
> 
> Several ocamlbuild-related questions:
> 
> 1 - Is there a simple reason why ocamlbuild is a tool with plugins
> and not a library ? It would be much easier to adapt it to other
> contexts than ocaml compiling, and to larger projects. In my
> projects, a myocamlbuild.ml file must be written most of the time,
> so I do not understand the point.

I am afraid I do not grasp the dichotomy you draw between a tool
and a library, as ocamlbuild plugins are actually compiled against
the ocamlbuild library. Could you elaborate on what you feel wrong
with this approach?


> Another point I see is that I usually spend a non-negligible part of
> my time writing makefiles and myocamlbuild files. Since I must do it
> anyway, I'd like to write all that in pure ocaml, doing argument
> parsing as I want, adding arguments if I want, and even doing some
> configure steps in ocaml before starting to compile anything. Using
> output_value to do this (as I did for
> http://lama.univ-savoie.fr/~meunier/camlimages for instance) is much
> easier than outputing _tags and .mlpack in subdirectories.

Well, the first thing to notice is that the ocamlbuild API is not
cast in stone, and a tool like camlp4 provides an API allowing to add
command-line switches via plugins. However, I have found myself that
the question of parameter passing can often be done through tags.
As for auxiliary files, it is frequent for me (in personal projects)
to create mlpack files from the myocamlbuild file. Indeed, I think
that it is even necessary to be really flexible about file addition
or deletion (but, of course, this implies to have some sort of "rule"
to determine which modules should be packed).


> Also, it would be nice to allow it to depend on other modules, even
> of some files of the project you are compiling. Examples of uses
> include configuration options, versions, etc.

I beg to differ with this ability to interleave application code and
build code. That being said, nothing prevents you from tweaking your
myocamlbuild file at configuration step.


> 2 - Also, I do not understand why I get the following message:
> 
> Failure: Included or excluded directories must be implicit (not
> "../_build").
> 
> Is it a technical restriction to avoid copying entire filesystems to
> _build if the _tags are ill-written, or is there another reason ?

Let me ask you the dual question: why is this restriction causing you
some trouble?


> 3 - Finally, I find the idea of tags good, for backward compatibility
> reasons (you do not have to change your code), but not enough. For
> instance, in haskell (and some compilers written in ocaml), you can
> add "tags" at the beginning of your files. You would start your
> ocaml files with comments such as:
> 
> (* #OPTIONS -rectypes *)

Well, I find tags pretty convenient, and do not dislike the comment
approach. However, I am pretty sure I do not want the related information
to be scattered over multiple locations.


Kind regards,

Xavier Clerc