caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: "Frédéric Bour" <frederic.bour@lakaban.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] why is building ocaml hard?
Date: Mon, 11 Jul 2016 12:36:25 +0200	[thread overview]
Message-ID: <1468233385.25014.97.camel@e130.lan.sumadev.de> (raw)
In-Reply-To: <c4ccb268-95a3-9974-3a64-879a149d8eb6@lakaban.net>

[-- Attachment #1: Type: text/plain, Size: 2960 bytes --]

Am Montag, den 11.07.2016, 16:22 +0900 schrieb Frédéric Bour:
> - the compiler driver can produce multiple files on a single
> invocation. File level dependencies turn into an hypergraph rather
> than a graph (making a Makefile driven system hardly stable)

Just a comment on this point. This is actually not a big problem when
you record which rules have already been run, because then you can
consider

file1 file2 file3: file4 file5 file6
    cmd

just as

file1: file4 file5 file6
    cmd
file2: file4 file5 file6
    cmd
file3: file4 file5 file6
    cmd

This is what omake does (and the rules are identified by their MD5
digests, which is very reliable).

The limitation is that you cannot handle overlapping targets well,
something like

file1 file2: file4
    cmd1
file1 file3: file4
    cmd2

but this is something hardly any build system can do (i.e. alternate
rules).

Gerd

> - an ML file alone is hard to understand out of context, because build
> specification are kept separate
> - many names and partially overlapping concepts; top-modules,
> libraries, ocamlfind packages, opam packages.
> 
> On 07/11/2016 03:15 PM, Martin DeMello wrote:
> 
> > On Sun, Jul 10, 2016 at 4:03 AM, Gerd Stolpmann
> > <info@gerd-stolpmann.de> wrote:
> >         So how to fix this? In my opinion there are two solutions.
> >         You can
> >         either have a more intelligent ocamldep (e.g. one that reads
> >         in
> >         non-local cmi files and uses that information and also tries
> >         to
> >         interpret all project ml files at once and not file by file
> >         - btw, did
> >         anybody check whether there is an algorithm that precisely
> >         solves the
> >         problem?). The other solution path is to mark toplevel
> >         modules in the
> >         syntax of OCaml (e.g. you'd have to do "open ^M2" is M2 is a
> >         toplevel
> >         module).
> > 
> > 
> > Would an acceptable third option be to simply record the dag
> > explicitly in your build file? Working with google's build system
> > [opensourced as bazel: http://www.bazel.io/] has given me a great
> > appreciation for simply writing out build dependencies manually;
> > sure, it is relatively tedious to have to write out the graph
> > yourself rather than have ocamldep figure it out, but the time and
> > effort to do so is a small fraction of the overall development time
> > of your project, and the reward is a 100% reliable "detection" of
> > the build topology.
> > 
> > 
> > martin 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-07-11 10:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-10  4:16 Martin DeMello
2016-07-10 11:03 ` Gerd Stolpmann
2016-07-10 11:33   ` [Caml-list] Is there an efficient precise ocamldep - Was: " Gerd Stolpmann
2016-07-10 11:51     ` Petter A. Urkedal
2016-07-10 22:41   ` [Caml-list] " Tom Ridge
2016-07-11  6:15   ` Martin DeMello
2016-07-11  7:22     ` Frédéric Bour
2016-07-11 10:36       ` Gerd Stolpmann [this message]
2016-07-13 12:10       ` David Allsopp
2016-07-11  9:14     ` Malcolm Matalka
2016-07-12  8:18   ` Goswin von Brederlow

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=1468233385.25014.97.camel@e130.lan.sumadev.de \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=frederic.bour@lakaban.net \
    /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).