English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-04-17 (02:31)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] build tools - good vs. fast, both cheap
On Sat, 2004-04-17 at 07:53, William Lovas wrote:
> On Sat, Apr 17, 2004 at 12:38:08AM +1000, skaller wrote:

> This is essentially the goal of the GODIVA project (formerly GODOR) that
> Owen Gunden and i are working on:  We're grafting a sensible specification
> onto the frontend of GODI so that it's easier for developers to make
> packages. 

>     http://projects.phauna.org/godiva/papers/godiva.ps
>     http://projects.phauna.org/godiva/papers/godiva.pdf

OK, I've read this now, especially the most interesting part,
the build policy. Since I don't know what constraints are
Godiva's, and which are Godi's and which are bsd's .. I'll
just make some comments.

I'm going to see how this would go installing Felix.

(1) Make all/make opt.

What I do is:

make compiler
make compiler.bytecode

There is a reason for this. First, the target is 'compiler'
and not 'all'. "all" is a lot more than just the tools
generated by ocaml, see below.

Second, make compiler automatically makes the native
code version if possible, otherwise it makes the bytecode
version. The compiler.bytecode target makes bytecode only.

(2) make htdoc

I wish it were that simple. The felix documentation
consists of the following, at least:

(a) A complete typeset listing of the source code.
(b) An Ocamldoc generated module reference.
(c) Several tutorials
(d) A reference manual (not written yet :)
(e) A users guide (not written yet)
(f) Theory and principles papers (not written yet)
(g) Typset listing of test inputs (other than the tutorial
codes which are in fact the primary unit tests).
There are two sections at the moment: special regression
and unit tests, and a set of performance tests.
(h) Man pages, including HTML formatted versions of them

In addition, interscript "in theory" can generate
documentation in any language: technically a few
navigation bars can be done in English, Spanish etc,
however there is a possibility of selecting a non-native
language section (a paragraph could be provided in several
languages). The point here is that the choice of languages
is a mandatory command line parameter: there is, deliberately,
no default. Note also the plural. You can simultaneously
generate documentation in any number of languages, the
files are prefixed by the ISO language code: en_ for english,
es_ for spanish, fr_ for French (thought I'd better add that
one here .. ). Etc.

So there needs to be a way for the client to configure that.
[There isn't at present, even in my build scripts]

The generated documentation doesn't all go in the same place.
The tutorial goes in tutorial/doc. The ocamldep output goes
into impldoc, the html listing into doc, and the html man
pages into htmlman.

(3) Missing targets.

First: there are test targets. Running the tests is considered

Second: Felix itself is a compiler. Naturally IT has a 
standard library and there are some tools written in it.
These must be built and tested too .. 

Third: Felix can call C libraries via wrappers.
These wrapper have to be generated. At the moment I'm
using SWIG with a custom module which can't be used
with SWIG without first patching it. So SWIG needs
to be relinked and installed (the patched version
makes an extra executable).

Then there has to be a way to determine *which* libraries
to wrap. The current method is intended to be: everything
there is a SWIG wrapper for, if the library exists, PLUS,
every library in the systems pkg-config database PLUS
any the user specifies. Wrappers get generated even if there
is no SWIG annotation file. Maybe :D

(4) Bootstrapping problem.

Felix consists of LP source codes. When you unpack the
tarball, there is a 'courtesy' makefile to bootstrap
the system. To get the thing rolling you have to do this:

make boot
make extract compiler drivers tests .......

The actual Makefile.ac is extracted by make boot,
then configure creates the makefile from it.
Make boot currently runs autoconf and friends
to generate the configure script from configure.ac.



Felix installs much as described in A.1, except there
is more. In fact some components are a nightmare.
For example 'felix.vim' has to go in


but that isn't enough (some other files have to be patched)
which is a design flaw in vim.

Much of Felix actually lives in


because this is the kind of thing Ocaml and Python do.
The suggested /usr/local/share/felix isn't used,
because most of the shared data is actually Felix
program source.

The installation point for generated wrappers is a nightmare!



A mandatory

make test

target. The test must be run by GODI, and installation
refused if it fails. 

More is needed but my brain is overloaded now :D

John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners