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 C189F7FE36 for ; Mon, 11 Jul 2016 17:56:45 +0200 (CEST) IronPort-PHdr: 9a23:MuC9EhASrFaYG1vXxz71UyQJP3N1i/DPJgcQr6AfoPdwSPj+o8bcNUDSrc9gkEXOFd2CrakV06yN7uu+BSQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd+KyZ/qnL7us7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWcQCH0u/MDgqTXESAKO4DNcDjRXwVJ0BF2P1xb3UYvrtTO+/s980ymTMMm8BeQxWD+i5qpvDgTvhSgbLTkh2GDRlsF0yqlcpUTl7z54xYfIYIiTfMJkeb/PcNUZQiIVXMFXXjBBC4X6d5EIE/gMO+Vfh4b4rloK6xC5AF/oTKnXxyNUi2W+9Oty7v4iHA3P2EZoS8oHrW7Xodn8MI8dVOm0yO/DyjCVK7t50D3n6YXMOisqofyWUKg4JcXYw1MuGgeDlV6QpJboJRua0+0Mty6Q6O82Bsy1jGtyhQh7uDmky48Ih8Hni5kOw1bYvXFXyYwvJNa1Dmp2VtCpC4BZsT2yNo1sQ8pkTXs+63Vy8aEPpZPuJHtC858g3ROKLqHefg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=Fabrice.Le_fessant@inria.fr; spf=Pass smtp.mailfrom=fabrissimo@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-f53.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of Fabrice.Le_fessant@inria.fr) identity=pra; client-ip=74.125.82.53; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="Fabrice.Le_fessant@inria.fr"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of fabrissimo@gmail.com designates 74.125.82.53 as permitted sender) identity=mailfrom; client-ip=74.125.82.53; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; 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-wm0-f53.google.com) identity=helo; client-ip=74.125.82.53; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-wm0-f53.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0COAAAzwYNXfzVSfUpchAcNfIRIowCMMYUEghyHIjgUAQEBAQEBAQERAQEJCwsJHzGCMgQBEoIUAQQBEhEmJQsFCwkCCxodAgIiEgEFAQoSBgESEhCHdAMPCA6TLo9CgTE+MYs7ikkDhAgBAQgBAQEBAQEhEIpkh0KCWgWGVAySOIYNiEWCOIx0jlAwgQ8PD4I/HIFMPDKJPwEBAQ X-IPAS-Result: A0COAAAzwYNXfzVSfUpchAcNfIRIowCMMYUEghyHIjgUAQEBAQEBAQERAQEJCwsJHzGCMgQBEoIUAQQBEhEmJQsFCwkCCxodAgIiEgEFAQoSBgESEhCHdAMPCA6TLo9CgTE+MYs7ikkDhAgBAQgBAQEBAQEhEIpkh0KCWgWGVAySOIYNiEWCOIx0jlAwgQ8PD4I/HIFMPDKJPwEBAQ X-IronPort-AV: E=Sophos;i="5.28,347,1464645600"; d="scan'208,217";a="184531069" Received: from mail-wm0-f53.google.com ([74.125.82.53]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 11 Jul 2016 17:56:44 +0200 Received: by mail-wm0-f53.google.com with SMTP id o80so57517930wme.1 for ; Mon, 11 Jul 2016 08:56:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3/JdZndq5t03mvrT1jPnqyaLkA/sz50oHXXUsLdR86k=; b=OBqUDDBESYRQmC8jDQy0MoubCCYDXPcAezdzFkCSZzD0cLiC0d5zzg6KxyP/DUHOBF lFwanHZqOAN0guiO35X7QYTZoLpdNX29SWxPecYElWHkfW2FmH2fVujIlO3G4+aXin3h Oz0ZYm8pfWfyciv5XO1o/c2fGKApmWpKUhrrJUyFIf7oxiq6+KUPcS6v/NowpWtdrAqw B2G/HXRhKIh8MAeEbsFLXLjQ1/xzfj3u7phQgJ7ddzhUfeM07bL8Su5xlcszNyL2ce+A 62IKeC9U6xbWJ40v6iAzgRS9Dhj5dEBdROjcCD+N6PEdoV0lBqxQUmL0A8qRBcanXjCl DTaw== X-Gm-Message-State: ALyK8tLPgcSZ5UkFbJ1aq8gBIHMfWH8zcQIf/2gwb8WjsNWsBgl2/YqwXYDhtATJlFyKIDeQwaVGHRTMryybDw== X-Received: by 10.28.218.67 with SMTP id r64mr20630366wmg.10.1468252604472; Mon, 11 Jul 2016 08:56:44 -0700 (PDT) MIME-Version: 1.0 References: <0F7D3B1B3C4B894D824F5B822E3E5A172CF204AF@IRSMSX102.ger.corp.intel.com> <0F7D3B1B3C4B894D824F5B822E3E5A172CF20547@IRSMSX102.ger.corp.intel.com> <2782bd72-cd55-d2af-37d9-2d097bdeef2b@gmail.com> <0F7D3B1B3C4B894D824F5B822E3E5A172CF2089A@IRSMSX102.ger.corp.intel.com> <0F7D3B1B3C4B894D824F5B822E3E5A172CF20C2B@IRSMSX102.ger.corp.intel.com> In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CF20C2B@IRSMSX102.ger.corp.intel.com> From: Fabrice Le Fessant Date: Mon, 11 Jul 2016 15:56:35 +0000 Message-ID: To: "Soegtrop, Michael" , Jonathan Protzenko , "Petter A. Urkedal" , Gabriel Scherer Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a11469992ee3ee205375e32fb Subject: Re: [Caml-list] ocambuild vs ocamldep circular dependencies --001a11469992ee3ee205375e32fb Content-Type: text/plain; charset=UTF-8 FWIW, `ocp-build` has a specific variable to overcome `ocamldep` limitations. You can for example describe a library like that: ``` begin library "foobar" requires = [ "unix" "my-other-lib" ] files = [ "bar.ml" (nodeps = [ "Foo" ]) (* <---- module Bar does not depend on Foo, even if `ocamldep` says the contrary *) "foo.ml" ] end ``` It also has a specific algorithm to discover cycles in build rules and display the cycle in a user-friendly fashion, so that finding the arguments for `nodeps` becomes easier. --Fabrice On Mon, Jul 11, 2016 at 5:33 PM Soegtrop, Michael < michael.soegtrop@intel.com> wrote: > Dear OCaml Users, > > a note for those reading this thread later: > > I finally used the module rec approach as outlined by Petter A. Urkedal in > his previous post, although some people said in various places that this is > overkill if you have issues with just a few functions. The module structure > implied by the module rec approach was in the end nicer than my original > module structure (which didn't work cause of the circular dependency). It > was also much less work to restructure the modules than I thought. I tried > several other approaches (function references, putting all functions > calling each other into one file, treat mli and ml files separately in the > build system), but they all appeared to be inferior, either in terms of > effort or in terms of clarity, usually both. > > So I came to the conclusion that long term there is no issue with properly > declaring recursive module structures using "module rec", although it can > be quite a pain short term. For resolving some short term hacks (e.g. for > experiments), one can still use the function reference approach. > > Best regards, > > Michael > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --001a11469992ee3ee205375e32fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW, `ocp-build` has a specific variable to overcome= `ocamldep` limitations.

You can for example descr= ibe a library like that:

```
begin libra= ry "foobar"
=C2=A0 requires =3D [ "unix" &quo= t;my-other-lib" ]
=C2=A0 files =3D [=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0"bar.ml" (nodeps =3D [ "Foo" ]) =C2=A0 =C2=A0(* = =C2=A0 <---- module Bar does not depend on Foo, even if `ocamldep` says = the contrary *)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0"foo.ml"
<= div>=C2=A0 =C2=A0]
end
```

It = also has a specific algorithm to discover cycles in build rules and display= the cycle in a user-friendly fashion, so that finding the arguments for `n= odeps` becomes easier.

--Fabrice



On = Mon, Jul 11, 2016 at 5:33 PM Soegtrop, Michael <michael.soegtrop@intel.com> wrote:
Dear OCaml Users,

a note for those reading this thread later:

I finally used the module rec approach as outlined by Petter A. Urkedal in = his previous post, although some people said in various places that this is= overkill if you have issues with just a few functions. The module structur= e implied by the module rec approach was in the end nicer than my original = module structure (which didn't work cause of the circular dependency). = It was also much less work to restructure the modules than I thought. I tri= ed several other approaches (function references, putting all functions cal= ling each other into one file, treat mli and ml files separately in the bui= ld system), but they all appeared to be inferior, either in terms of effort= or in terms of clarity, usually both.

So I came to the conclusion that long term there is no issue with properly = declaring recursive module structures using "module rec", althoug= h it can be quite a pain short term. For resolving some short term hacks (e= .g. for experiments), one can still use the function reference approach.

Best regards,

Michael

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs --001a11469992ee3ee205375e32fb--