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 C4A887FCCD for ; Tue, 12 Jul 2016 10:33:13 +0200 (CEST) IronPort-PHdr: 9a23:xcdvJxf/9/WfX0RvSvTyzZdrlGMj4u6mDksu8pMizoh2WeGdxc65bB7h7PlgxGXEQZ/co6odzbGH6+a7BydZu8/JmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/mj6bppdaKOVwArQH+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6Lpyv/JHBK7zeqB9Sb1DEBwnNXo07Yvlr0rtVwyKs1QbSXoXlFJWBA6Nxgv3Uprrtizl/r5y3zKFPMuzU/U+cSuv5eFnRUm72288Kzcl/TSP2YRLh6VBrUf5qg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=goswin-v-b@web.de; spf=Pass smtp.mailfrom=goswin-v-b@web.de; spf=None smtp.helo=postmaster@mout.web.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=217.72.192.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of goswin-v-b@web.de designates 217.72.192.78 as permitted sender) identity=mailfrom; client-ip=217.72.192.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; 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@mout.web.de) identity=helo; client-ip=217.72.192.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWAACSqoRXh07ASNlchBR8sG+IGIF6GoV+AoEwOBQBAQEBAQEBAREBAQEIDQkJIS+CMhWCFQEBBAEjDwEWNQsLGAICBSECAg8FKDQbh3oBEggEsAeKDx+ENgELASSBAYl2h0Irgi8FmRqOSolJCoVkkBIeglCBWWyJJQEBAQ X-IPAS-Result: A0BWAACSqoRXh07ASNlchBR8sG+IGIF6GoV+AoEwOBQBAQEBAQEBAREBAQEIDQkJIS+CMhWCFQEBBAEjDwEWNQsLGAICBSECAg8FKDQbh3oBEggEsAeKDx+ENgELASSBAYl2h0Irgi8FmRqOSolJCoVkkBIeglCBWWyJJQEBAQ X-IronPort-AV: E=Sophos;i="5.28,351,1464645600"; d="scan'208";a="184590322" Received: from mout.web.de ([217.72.192.78]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2016 10:33:12 +0200 Received: from frosties.localnet ([134.3.242.84]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0Lu52Q-1bDRE93jx0-011SYO for ; Tue, 12 Jul 2016 10:33:11 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.87) (envelope-from ) id 1bMt7v-00014P-2I for caml-list@inria.fr; Tue, 12 Jul 2016 10:33:11 +0200 Date: Tue, 12 Jul 2016 10:33:11 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20160712083310.GB919@frosties> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CF204AF@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:bIsyDqCpeetHOn4kWHcgYDTT8aqccMTbfupEciJvylOBFm8/YiP ExdJjY0GPr5oSbBF8+7H/JdzKKx/Iaqi32hr6J710up7rX0sHIYSYaAvSFAJFbnWfyx+Dt9 isL9OQ8EmOAlhwN54zMwNw2dUBfvwnnsRLm/a13+O8GN7d1aIbA7VTEz+0gisjkt+eDu+Aw roK2E41ZughDMdVuC43mg== X-UI-Out-Filterresults: notjunk:1;V01:K0:PD1a6wctnwk=:902brpdRn9CvK23jC71L17 zR+328tYTUF1vIM8paNyY/cJ5PBnbYDMx9D6mMHkuBiNTLshHlExI5Mx0a/zc3SZVZ6M0CCnq mRQ/oSTWSPiWfUb9M9j70qyrfGcajd1UZj+YFFR7kdrHO/N0AokEcGGZqIMpx1JH8xrujKiD7 rhtpBtweLH9Y4j16OQsBOaauHjpp0cg+px5FnnXjZV0iroZX5iynJbA7ciaSNzSYBYMX6mD3L UR3ag6p/dmMuM2R3qwIAeorRaXD5JnycHJP5ks4ALxRQj56tl2Bty05IGYOIwy6Mso2a50qK2 nb9QarYeA2zAZ6dJe4lVdI/LBr21r3WgHohpS1P8dL34zYEsnGJE7KH1mhuF8zYOvk/WTx3wF EDGIShOscaqYWbwfbu0XRnZhjZeOCuCSYO9DMJXQXS+4mQAwW1YmofRsafdxHrMwHUkJo4Z5u 9rkMhPly3lSQrJIh3T+2KFKOTk3PXAiS5xispcm/cO6FqsEu24FX+s9QhO1mhajwukF+MhbYn 4lRxUBCcEQBdGMNBxwvsyogErnUI74nD/fuYhK5jlTSfk66SjHiHfwgAqUP8YSPXc6x2x2tq1 aqGmd20MQ7HDX1gqcY6KkokFt2dm+Sb7ovhoumOXyVbU7OjANv3RkldtCHaF6tvr4fotlR4JP ScUZoRVqW+fiMpGZw0YRij24hwXe8vQy7NgUj4ipx1m9CmTomFHEpdi4ht8uRap+9C5BOJmnZ OD3BHrV3n9mFIPdfDG6vLRSr3ujSij+wlErvmOpgQX6ahZYOWTmC/AOR4g8= Subject: Re: [Caml-list] ocambuild vs ocamldep circular dependencies On Sat, Jul 09, 2016 at 09:45:46AM -0400, Gabriel Scherer wrote: > Hi Michael, > > > > One can of cause discuss if it is good style to have circular dependencies > > between module implementations. One can also discuss if it is the job of a > > build tool to enforce such policies, or if a build tool should reduce the > > set of valid programs. > > > I think there is a misconception here. The behavior of the compiler in > presence of such circular dependencies is undefined. The current > implementation happens to allow them, but this does not mean that they are > "valid programs". I thought that only worked with hacks, turning of cross module inlining to make it build at all. > On Sat, Jul 9, 2016 at 8:53 AM, Soegtrop, Michael < > michael.soegtrop@intel.com> wrote: > > > Dear OCaml Users and Developers, > > > > It has been discussed a few times on the list, that ocambuild treats .mli > > and .ml files as one regarding dependencies (unlike ocamldep), so that > > projects which have dependencies of the type A.ml depends on B.mli and B.ml > > depends on A.mli, cannot be built with ocamlbuild, although they can be > > built by other means. > > > > One can of cause discuss if it is good style to have circular dependencies > > between module implementations. One can also discuss if it is the job of a > > build tool to enforce such policies, or if a build tool should reduce the > > set of valid programs. > > > > Let me describe the issue which gives me headaches right now. I am working > > on a tool doing certain analysis on C programs. In this tool I have a > > module handling types and a module handling constant folding. Both have a > > circular dependency in their implementation. Look e.g. at this case: > > > > sizeof(int[3*4])*2 > > > > The type handling module needs to call the constant folding module to get > > the value of 3*4. The constant folding module needs to call the type module > > for handling the sizeof. There are no easy ways around the circular > > dependency here. One way would be to have a mutable value field in my AST > > and write the folded values to the AST while doing constant folding, so > > that the type module can access the value when it needs it. I have my > > doubts that this is nicer than living with the circular dependency. Anyway > > I want to be able to decide this and not be forced to a solution by a build > > tool. I think there are many cases, where two modules are just handling > > different aspects of a common complex data structure (in this case a C AST) > > and there is no natural ordering between them. I don't think you have explored all the ways around the circular depends yet. 1) factor out the common parts into a 3rd module used by both 2) use recursive modules 3) lift the recursion (old style): pass a record of callbacks to one of the modules to replace the cyclic calls 4) lift the recursion (first class modules): pass one of the modules as argument to the other and open it locally > > As a result I would recommend to support in ocamlbuild the same dependency > > model as ocamldep has (things are fine as long as .mli files don’t have > > circular dependencies). > > > > The only way I see right now to get my job done is to discard ocamlbuild > > and use OcamlMakefile. Since I use menhir –infer, I first have to modify > > OcamlMakefile to handle dependencies in way menhir can live with. > > > > 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 > > MfG Goswin