From: Fabrice Le Fessant <fabrice@lefessant.net>
To: Pierre-Etienne Meunier <pierreetienne.meunier@gmail.com>
Cc: O Caml <caml-list@inria.fr>
Subject: Re: [Caml-list] About ocamlbuild
Date: Sat, 17 Nov 2012 18:21:48 +0100 [thread overview]
Message-ID: <CAHvkLrM6Ts_JVpS+zNH9zK7CbAMVCtm+5w8ufYsg6Nh21yYnGg@mail.gmail.com> (raw)
In-Reply-To: <BBA74930-79F4-4C9D-871A-719113837891@gmail.com>
Hi,
On Fri, Nov 16, 2012 at 12:43 PM, Pierre-Etienne Meunier
<pierreetienne.meunier@gmail.com> wrote:
> So compiling everything without duplication is not that trivial, and I really would like to write an ocaml program to compile it, maybe using a more complex build system than just one file with the ocamlbuild api. I understand that ocamlbuild is still in an early stage of development, this is why I'm sending these mails. The code is split among different directories, and using a library interface in the compilation of another library still seems difficult in ocamlbuild today. The documentation explains how to use an internal library in program, but it forces you to use a particular layout of your files. This is why I feel that a library would be more versatile: we can imagine a makefile compiling the build system first, possibly split between several modules, then calling it to compile the rest, like xmonad does, for instance.
Actually, this use case is exactly the reason why I developed the
"ocp-build" tool (you might have used it if you tried to compile
opam). It's much less powerful than ocamlbuild, but for what it does,
it is much simpler to use. The idea is to write a simple description
of the package contained in each directory. The tool then scans all
the sub-directories looking for these descriptions (in files with .ocp
extensions), use the specified dependencies between packages to order
them, and then build all of them incrementally (no unnecessary
rebuild) and in parallel.
Since the description is only for OCaml files, it is very simple and
short, but of course, if you are doing complicated things, you won't
be able to express them in such a simple language...
There is currently no documentation, and 'opam install ocp-build' will
install a one-year old version (but latest sources are in the typerex2
branch of typerex), so I would not advise anybody to use it curently,
except for playing, but I (and some others in my team) found that it
is a convenient tool for most of our needs.
For example, the opam file looks like :
begin
comp += [ "-g" "-annot" "-warn-error" "A" ]
link += [ "-g" ]
begin library "opam-lib"
subdir = [ "src" ]
files = [
"opamGlobals.ml" ...
"repo/opamGit.ml" "opamSolver.ml" "opamClient.ml"
]
requires = [ "cudf" "dose" "unix" "graph" "re_glob" ]
end
begin program "opam"
subdir = [ "src" ]
files = [ "opamMain.ml" ]
requires = [ "opam-lib" "arg" ]
end
begin program "opam-mk-repo"
files = [ "src/scripts/opam_mk_repo.ml"]
requires = [ "opam-lib" ]
end
begin program "opam-check"
files = [ "src/scripts/opam_check.ml" ]
requires = [ "opam-lib" ]
end
begin program "opam-repo-check"
files = [ "src/scripts/opam_repo_check.ml" ]
requires = [ "opam-lib" ]
end
end
Among the current drawbacks, there is no compatibility with findlib
descriptions, nor any easy way to guess the current installed
packages, so you have to create a file describing your environment.
For example, in opam, it comes with a file 'ocaml-libs.ocp'
containing:
begin
generated = true
dirname = [ "%{OCAMLLIB}%" ]
has_byte = true
has_asm = true
begin library "unix" end
begin library "str"
requires = [ "unix" ]
end
begin library "dynlink" end
begin library "camlp4fulllib"
requires = [ "dynlink" ]
has_asm = false
end
begin library "bigarray" end
begin library "threads"
dirname = [ "%{OCAMLLIB}%/threads" ]
end
end
to describe all the default libraries. We hope that the tool, at some
point, will be able to either read META files, or packages will come
with an .ocp file describing them...
Finally, another nice thing is the "packing" syntax. For example, to
compile sexplib with ocp-build, we use :
begin library "sexplib"
files = [
pack Sexplib [
"type.ml"; "parser.mly"; "lexer.mll"
"pre_sexp.ml" ( pp = [ "cpp"; "-undef"; "-traditional" ] );
"sexp_intf.ml"; "sexp.ml";
"path.ml" "conv.ml" "conv_error.ml" "exn_magic.ml" "std.ml"
]
]
requires = [ "bigarray" "nums" ]
end
to pack all the modules within the "Sexplib" module.
--Fabrice
next prev parent reply other threads:[~2012-11-17 17:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-15 12:05 Pierre-Etienne Meunier
2012-11-15 21:48 ` Xavier Clerc
2012-11-15 22:04 ` Edgar Friendly
2012-11-15 22:36 ` Xavier Clerc
2012-11-16 10:33 ` Arnaud Spiwack
2012-11-16 10:53 ` Gabriel Scherer
2012-11-16 11:43 ` Pierre-Etienne Meunier
2012-11-16 19:05 ` [Caml-list] " Hongbo Zhang
2012-11-16 19:33 ` [Caml-list] " Wojciech Meyer
2012-11-17 17:21 ` Fabrice Le Fessant [this message]
2012-11-16 11:01 ` Daniel Bünzli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHvkLrM6Ts_JVpS+zNH9zK7CbAMVCtm+5w8ufYsg6Nh21yYnGg@mail.gmail.com \
--to=fabrice@lefessant.net \
--cc=caml-list@inria.fr \
--cc=pierreetienne.meunier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).