From: Malcolm Matalka <mmatalka@gmail.com>
To: Martin DeMello <martindemello@gmail.com>
Cc: "caml-list\@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] why is building ocaml hard?
Date: Mon, 11 Jul 2016 09:14:31 +0000 [thread overview]
Message-ID: <86r3b0iljc.fsf@gmail.com> (raw)
In-Reply-To: <CAFrFfuGLRLam3AWac9OnWF5VQfzFBzjqhtswNwNscXuUz57N+w@mail.gmail.com> (Martin DeMello's message of "Sun, 10 Jul 2016 23:15:37 -0700")
Martin DeMello <martindemello@gmail.com> writes:
> 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
I've created a build tool called pds (in opam, although a newer version
needs to be released) which is meant to be really easy to go from
nothing to a compiling project that installs. One problem I found with
the various Ocaml build systems was that they were very flexible, which
can be nice, but also made them more complicated. I was willing to
sacrifice flexibility for simplicity.
The README for the current version can be found here:
https://bitbucket.org/mimirops/pds/raw/95da73d295d790c82ed900a76880a402b9120b49/README.org
I'm sure there are bugs in there, especially the Makefile it generates,
but I use it on all of my projects with success. It does rely heavily
on ocamldep to come up with the correct order to compile things within a
project.
/Malcolm
next prev parent reply other threads:[~2016-07-11 9:14 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
2016-07-13 12:10 ` David Allsopp
2016-07-11 9:14 ` Malcolm Matalka [this message]
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=86r3b0iljc.fsf@gmail.com \
--to=mmatalka@gmail.com \
--cc=caml-list@inria.fr \
--cc=martindemello@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