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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 8731A7FE44 for ; Sat, 9 Jul 2016 14:53:36 +0200 (CEST) IronPort-PHdr: 9a23:zCU5YhQvCC1zo98O05OFJ6aHU9psv+yvbD5Q0YIujvd0So/mwa64YhON2/xhgRfzUJnB7Loc0qyN4vimAjdLvM/JmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/mj6bpoNaOOk1hv3mUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD86Fpy8kVG67zeqB9Sb1DEBwnNXo07Yvlr1OLGQCG439ZVmQNjjJJBRLE5Vf0RMGinDH9s7834y6XMtHsSqhwERGj5KdiRRuiwHMCNjU5+WzTzNd3ga1HuhW5jx1534PQJoqSMawtLevmYdoGSD8ZDY5qXCtbD9bkYg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=michael.soegtrop@intel.com; spf=Pass smtp.mailfrom=michael.soegtrop@intel.com; spf=None smtp.helo=postmaster@mga04.intel.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of michael.soegtrop@intel.com) identity=pra; client-ip=192.55.52.120; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="michael.soegtrop@intel.com"; x-sender="michael.soegtrop@intel.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of michael.soegtrop@intel.com designates 192.55.52.120 as permitted sender) identity=mailfrom; client-ip=192.55.52.120; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="michael.soegtrop@intel.com"; x-sender="michael.soegtrop@intel.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mga04.intel.com) identity=helo; client-ip=192.55.52.120; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="michael.soegtrop@intel.com"; x-sender="postmaster@mga04.intel.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BDAAAD84BXh3g0N8BcgnCBJHwGuRaBehqFfgKBIjgUAQEBAQEBAQERAQEBCA0JCSEkC4IyFYIcLRxCASpWHwcBBBsTiBQBnyCeYzGGKIkPgkcLWIIvBZkSBgGdfZAPHoJQgVduiHsBfgEBAQ X-IPAS-Result: A0BDAAAD84BXh3g0N8BcgnCBJHwGuRaBehqFfgKBIjgUAQEBAQEBAQERAQEBCA0JCSEkC4IyFYIcLRxCASpWHwcBBBsTiBQBnyCeYzGGKIkPgkcLWIIvBZkSBgGdfZAPHoJQgVduiHsBfgEBAQ X-IronPort-AV: E=Sophos;i="5.28,336,1464645600"; d="scan'208,217";a="226169253" Received: from mga04.intel.com ([192.55.52.120]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Jul 2016 14:53:34 +0200 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 09 Jul 2016 05:53:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,336,1464678000"; d="scan'208,217";a="1003718257" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga001.fm.intel.com with ESMTP; 09 Jul 2016 05:53:32 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.10]) by IRSMSX103.ger.corp.intel.com ([169.254.3.240]) with mapi id 14.03.0248.002; Sat, 9 Jul 2016 13:53:30 +0100 From: "Soegtrop, Michael" To: "caml-list@inria.fr" Thread-Topic: ocambuild vs ocamldep circular dependencies Thread-Index: AdHZ3csMeHcHq0OFS7KZHyoJQn12uA== Date: Sat, 9 Jul 2016 12:53:30 +0000 Message-ID: <0F7D3B1B3C4B894D824F5B822E3E5A172CF204AF@IRSMSX102.ger.corp.intel.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: multipart/alternative; boundary="_000_0F7D3B1B3C4B894D824F5B822E3E5A172CF204AFIRSMSX102gercor_" MIME-Version: 1.0 Subject: [Caml-list] ocambuild vs ocamldep circular dependencies --_000_0F7D3B1B3C4B894D824F5B822E3E5A172CF204AFIRSMSX102gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Dear OCaml Users and Developers, It has been discussed a few times on the list, that ocambuild treats .mli a= nd .ml files as one regarding dependencies (unlike ocamldep), so that proje= cts which have dependencies of the type A.ml depends on B.mli and B.ml depe= nds on A.mli, cannot be built with ocamlbuild, although they can be built b= y 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 s= et 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 modul= e handling types and a module handling constant folding. Both have a circul= ar 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 t= he 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 depende= ncy here. One way would be to have a mutable value field in my AST and writ= e the folded values to the AST while doing constant folding, so that the ty= pe 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 abl= e to decide this and not be forced to a solution by a build tool. I think t= here 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 n= atural ordering between them. 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 cir= cular dependencies). The only way I see right now to get my job done is to discard ocamlbuild an= d use OcamlMakefile. Since I use menhir -infer, I first have to modify Ocam= lMakefile 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 --_000_0F7D3B1B3C4B894D824F5B822E3E5A172CF204AFIRSMSX102gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

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 o= camldep), 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 t= ool should reduce the set of valid programs.

 

Let me describe the issue which gives me headaches r= ight now. I am working on a tool doing certain analysis on C programs. In t= his tool I have a module handling types and a module handling constant fold= ing. 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 t= o call the type module for handling the sizeof. There are no easy ways arou= nd 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 tha= n 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 han= dling different aspects of a common complex data structure (in this case a = C AST) and there is no natural ordering between them.

 

As a result I would recommend to support in ocamlbui= ld the same dependency model as ocamldep has (things are fine as long as .m= li files don’t have circular dependencies).

 

The only way I see right now to get my job done is t= o 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

--_000_0F7D3B1B3C4B894D824F5B822E3E5A172CF204AFIRSMSX102gercor_--