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 1DEDD7EE48 for ; Sun, 25 Jan 2015 19:17:08 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dario.teixeira@nleyten.com) identity=pra; client-ip=217.70.183.197; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="dario.teixeira@nleyten.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dario.teixeira@nleyten.com) identity=mailfrom; client-ip=217.70.183.197; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="dario.teixeira@nleyten.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@relay5-d.mail.gandi.net) identity=helo; client-ip=217.70.183.197; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="postmaster@relay5-d.mail.gandi.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQBANcyxVTZRrfFnGdsb2JhbABag1hZBIJ8wzGFeQKBD0MBAQEBAREBAQEBAQYNCQkULoQNAQQBIxVGCwQHGgImAgJXBhsSiAoMvXiUAwwggSGOXoJogUEFkjmGazaNNIM7AoQQb4FEfgEBAQ X-IPAS-Result: AmQBANcyxVTZRrfFnGdsb2JhbABag1hZBIJ8wzGFeQKBD0MBAQEBAREBAQEBAQYNCQkULoQNAQQBIxVGCwQHGgImAgJXBhsSiAoMvXiUAwwggSGOXoJogUEFkjmGazaNNIM7AoQQb4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,464,1418079600"; d="scan'208";a="97634345" Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 25 Jan 2015 19:16:47 +0100 Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id C6C1541C06B for ; Sun, 25 Jan 2015 19:16:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8TRyHLZrCD8d for ; Sun, 25 Jan 2015 19:16:45 +0100 (CET) X-Originating-IP: 10.58.1.142 Received: from webmail.gandi.net (unknown [10.58.1.142]) (Authenticated sender: dario.teixeira@nleyten.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 589DA41C060 for ; Sun, 25 Jan 2015 19:16:45 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 25 Jan 2015 18:16:45 +0000 From: Dario Teixeira To: caml-list In-Reply-To: References: <7bca26c097b73f653bd8bbfa1a07eaa8@nleyten.com> <20150123164111.GA16664@yquem.inria.fr> <0fd907ee06bedeff816160b9e7b9c027@nleyten.com> Message-ID: <6829d3482c94fbe2e22dd1574618e86e@nleyten.com> X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/0.9.5 Subject: Re: [Caml-list] Forcing OCamlbuild to compile a file before another Hi Gabriel, > Currently there is nothing specific in ocamlbuild to support > -no-alias-deps. What the open(Foo) flag does is to to pass the "-open > Foo" option to ocamldep, which in turns merely adds Foo to the list of > dependencies of the compiled module. My understand of the situation > is that it guarantees that project using "-open ..." in their build > system will build correctly with ocamlbuild, with two limitations: > (1) if you use crazy recursive-but-not-really schemes, you'll get a > circular dependencies error (2) if Foo is a list of aliases, it will > act as a bottleneck in the dependency graph I've opted to abandon "-open Foo" and now explicitly declare "open Foo" on the source-code itself. Besides avoiding issues with the build system, I think the explicit approach will end up being clearer for someone reading the code (less knowledge about the system outside the source code itself). > Any good proposal to change the statu quo will of course be considered > -- but I myself have little time to implement new OCamlbuild features > -- > and I will try to be as reactive on possible bugs (eg. #6755) as > possible, > as the de-facto maintainer of ocamlbuild. Yeap, I understand. The good news is that it should be possible to use module-aliases/no-aliases-deps/pseudo-circular-recursion within the current OASIS+OCamlbuild framework with only minimal extra burden on the user, and zero modifications to OASIS or OCamlbuild. I had to bump my forehead against the wall a few times, but in the end I've managed to get the full combination working on a toy example, and I'm confident I can also get it to work on the much larger Lambdoc code base. I'll keep you posted... > I am not sure what should be done about (1). The almost-recursive > scheme was adopted by Jane Street for the extremely specific use-case > of migrating an enormous code-base from -pack to -no-alias-deps, but > I am not sure it is reasonable to expect it to work for other users > (and I doubt it's wise to advertise it as such). In my particular case, the impetus to abandon module packs stemmed not so much from the fat-binaries and recompilation problems, but from issues with the tooling (namely OCamldoc). Either way, there are enough advantages to module aliases and -no-alias-deps that I suspect more people will want to use them, even if they are not widely advertised. > In slightly more details: I think the idea of distributing a > short-name-giving lambwiki.ml to your users is a good way to emulate > -pack without the downsides of -pack, but that you could avoid using > the > short names in the project itself (that is use Lambda_Parser explicitly > rather than Parser). If you did this, the spurious cyclic dependencies > disappaear, you can simply use ocamlbuild without any dependency hack, > and your users see the short names. Yeah, using long names internally and short names externally is my fallback scenario. However, the Lambdoc core modules are used so extensively from within the library that it's worth spending some time trying to get short names to work internally too. Kind regards, Dario Teixeira