From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id B348D7FE36 for ; Mon, 11 Jul 2016 09:22:09 +0200 (CEST) IronPort-PHdr: 9a23:o4gEKREqqC+lABAyfx8KEJ1GYnF86YWxBRYc798ds5kLTJ75pMWwAkXT6L1XgUPTWs2DsrQf2rKQ6PyrAzNfqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ3pzxjLz5ocKMKyxzxxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cY6Lod8JtLWKD+OqA5VqBwDTI8Mmlz6te4mwPESF6h/PoQ038XmVJiBBXfpEX0RJr9vzH7vax33zSAFcn/Trk+UDLk6ap3Hky7wBwbPiI0pTmEwvd7i7hW9Uqs Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=frederic.bour@lakaban.net; spf=Pass smtp.mailfrom=frederic.bour@lakaban.net; spf=None smtp.helo=postmaster@mail.lakaban.net Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of frederic.bour@lakaban.net) identity=pra; client-ip=213.251.185.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="frederic.bour@lakaban.net"; x-sender="frederic.bour@lakaban.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of frederic.bour@lakaban.net designates 213.251.185.180 as permitted sender) identity=mailfrom; client-ip=213.251.185.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="frederic.bour@lakaban.net"; x-sender="frederic.bour@lakaban.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.lakaban.net) identity=helo; client-ip=213.251.185.180; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="frederic.bour@lakaban.net"; x-sender="postmaster@mail.lakaban.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBQD4R4NX/7S5+9VSCoQUKlK5FoF6GoV+AoFfEgEBAQEBAQEBZCeCMhWCFgEFIx0BATgPCxgnAwICRhETBgIBAReIFAWvJ2eEQwEBBYoFAQEIAgEcCIgfCIJNhBmCcQstglqOfoofjD+LYIVfkA8lDCOCCRyBW1+IcAEBAQ X-IPAS-Result: A0ApBQD4R4NX/7S5+9VSCoQUKlK5FoF6GoV+AoFfEgEBAQEBAQEBZCeCMhWCFgEFIx0BATgPCxgnAwICRhETBgIBAReIFAWvJ2eEQwEBBYoFAQEIAgEcCIgfCIJNhBmCcQstglqOfoofjD+LYIVfkA8lDCOCCRyBW1+IcAEBAQ X-IronPort-AV: E=Sophos;i="5.28,345,1464645600"; d="scan'208,217";a="184462170" Received: from pepper.lakaban.net (HELO mail.lakaban.net) ([213.251.185.180]) by mail3-smtp-sop.national.inria.fr with ESMTP; 11 Jul 2016 09:22:08 +0200 Received: from [192.168.179.6] (KD119104003216.au-net.ne.jp [119.104.3.216]) (Authenticated sender: defre@ygg-drasil.fr) by mail.lakaban.net (Postfix) with ESMTPSA id 6E126639817 for ; Mon, 11 Jul 2016 07:18:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lakaban.net; s=default; t=1468221499; bh=XEwr1YY5CoIK51hSakmX8gUioUosC8ATI6vZhmWYlok=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FXSod74PXwfwJ1hvLrjzz49sf7nqZpPGdMd3wHFsa3zYqZnH1dxVb+9r8JR9V7dBe 1w2KgfabJGiCCrt3/RgeB6Jz2ta+mQaf/cM6uWYXbzrrAjI81UHh5bOUbT7okopjvM ia2cO+mbXADxivhvC6sV5kAogauxhhocJxMxX9HU= To: caml-list@inria.fr References: <1468148606.25014.58.camel@e130.lan.sumadev.de> From: =?UTF-8?B?RnLDqWTDqXJpYyBCb3Vy?= Message-ID: Date: Mon, 11 Jul 2016 16:22:19 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7859E191B8CFEA37AABB0C42" Subject: Re: [Caml-list] why is building ocaml hard? This is a multi-part message in MIME format. --------------7859E191B8CFEA37AABB0C42 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I am beginning to think along those lines. Rather than just using top-modules and letting ocamldep guess dependencies, specifying them seems inherently more reliable and predictable. Maybe with something like an import statement. If this is done in each file, it should scale easily. Two things that might be related: - putting more build information in ml files (I recall that Gabriel Scherer mentioned that once, is that right?) - namespaces. More generally, I identify the following problems when building OCaml code: - under-specified dependencies, as discussed - 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) - 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 > > 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 --------------7859E191B8CFEA37AABB0C42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am beginning to think along those lines. Rather than just using top-modules and letting ocamldep guess dependencies, specifying them seems inherently more reliable and predictable.

Maybe with something like an import statement. If this is done in each file, it should scale easily.
Two things that might be related:
- putting more build information in ml files (I recall that Gabriel Scherer mentioned that once, is that right?)
- namespaces.

More generally, I identify the following problems when building OCaml code:
- under-specified dependencies, as discussed
- 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)
- 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 

--------------7859E191B8CFEA37AABB0C42--