caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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

  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).