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 16BC17F72A for ; Tue, 9 Aug 2016 20:31:17 +0200 (CEST) IronPort-PHdr: 9a23:QWJr5heV36pGxEtfnj1VpViblGMj4u6mDksu8pMizoh2WeGdxc+7ZR7h7PlgxGXEQZ/co6odzbGH6ua4ACdbuN7B6ClEK80UEUddyI0/pE8JOIa9E0r1LfrnPWQRPf9pcxtbxUy9KlVfA83kZlff8TWY5D8WHQjjZ0IufrymUrDbg8n/7e2u4ZqbO1wO32vkJ+srZ07v5UWJ749N0NMkcv5wgjLy4VJwM9xMwm1pIV/B1z3d3eyXuKBZziJLpvg6/NRBW6ipN44xTLhfESh0ezttvJ6jnVD5QACO/noRVHkN2loNWlCdrUKyYpCkiQWyk+Nn2zSBdeDyQ6o1Xzvqu6pvRgXpjigvKiU06nqRkcttlqlWrhW7qBE5xYPINtK7Lv17K4/UY9IWDUNFWt1WTzQJVo+mZs4JAvUaFeNVs4Dmu1IFrl21Agz6V7Cn8SNBmnKjhf5y6O8mCwyTmVV4R98= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=dra-news@metastack.com; spf=Pass smtp.mailfrom=dra-news@metastack.com; spf=None smtp.helo=postmaster@outmail148093.authsmtp.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.148.93; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of dra-news@metastack.com designates 62.13.148.93 as permitted sender) identity=mailfrom; client-ip=62.13.148.93; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.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@outmail148093.authsmtp.net) identity=helo; client-ip=62.13.148.93; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail148093.authsmtp.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CPAQAVIKpXh12UDT5dgxiBA3wHpBUBAQaWfRyCSoM3AoFMOxEBAQEBAQEBAREBAQEKCwkJGS+CMgQBEwGCEwEBBAE6PxACAQgYHhAyJQIEDg2IIQkDAcEzAQEBAQYBAQEBAQEBIIVihRWEQoMqgi8BBJk5hh2IbQqPOYhOh140gkOBV26GLX8BAQE X-IPAS-Result: A0CPAQAVIKpXh12UDT5dgxiBA3wHpBUBAQaWfRyCSoM3AoFMOxEBAQEBAQEBAREBAQEKCwkJGS+CMgQBEwGCEwEBBAE6PxACAQgYHhAyJQIEDg2IIQkDAcEzAQEBAQYBAQEBAQEBIIVihRWEQoMqgi8BBJk5hh2IbQqPOYhOh140gkOBV26GLX8BAQE X-IronPort-AV: E=Sophos;i="5.28,495,1464645600"; d="scan'208";a="229467637" Received: from outmail148093.authsmtp.net ([62.13.148.93]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Aug 2016 20:31:15 +0200 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u79IVD4k075491; Tue, 9 Aug 2016 19:31:13 +0100 (BST) Received: from romulus.metastack.com (114.212-105-213.static.virginmediabusiness.co.uk [213.105.212.114]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u79IVBiK071027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2016 19:31:12 +0100 (BST) Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id u79IQwZR008854; Tue, 9 Aug 2016 19:26:58 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0301.000; Tue, 9 Aug 2016 19:26:58 +0100 From: David Allsopp To: SF Markus Elfring CC: "moosotc@gmail.com" , Gabriel Scherer , "caml-list@inria.fr" Thread-Topic: [Caml-list] Interface(.mli) location Thread-Index: AQHR8aanWCvy6CNG7kmmtpBMUxmENKA/dJQwgADWe4CAAIcbsIAADGUAgAAR/LA= Date: Tue, 9 Aug 2016 18:26:57 +0000 Message-ID: References: <8737mfp7j3.fsf@gmail.com> <87y447npv3.fsf@gmail.com> <87r39znl6m.fsf@gmail.com> <378f6aa4-7e9d-19ee-2e45-93f386349703@users.sourceforge.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 72ee9c14-5e5f-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNl8UURhQ KkJXbgYSJgVNAnhE VHkJW1VSQFx4U2B0 YQtTIwdcYVRPXwB0 UklLXFNTEBpqBAMA SFsZW2AUBVw9eHlx ZURlEHFfWEJyO0F/ FxtdRmwCeGI1bTYC UUENcR5ccgofYx9F a1V+U3oINWACYDQC Ml17DBs4ODEaLCVO XjRFDFQOTFwFFzUx B1YHGTRuVUkCTCwv LhsgQl4B X-Authentic-SMTP: 61633634383431.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 213.105.212.114/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: RE: [Caml-list] Interface(.mli) location SF Markus Elfring wrote: > >>> a) Delete ./a.cmi as part of your build procedure. > >> > >> Can this design option trigger difficulties in your file system > >> configuration? > > > > What sort of difficulties do you mean? >=20 > Do software build systems track the existence of such a generated file? > > Are you also concerned about a harder parallelisation there? > > > d/a.cmi may constrain values defined in ./a.ml and you won't get the > > type-checking this way. >=20 > I would usually expect that these interface descriptions should be kept > consistent to some degree. Well yes, except that the compiler has two ways of interpreting an .ml file= . Consistency would be maintained in either scenario - when there's a .ml a= nd a .mli, the compiler will ensure that the interface of the Foo.ml and Fo= o.cmi unify, and you'll get a type error if they don't. Alternatively, if y= ou don't have Foo.mli (so Foo.cmi and Foo.cmo are both generated) and you l= ater try to link Foo.cmo with a module which expected it to comply with a d= ifferent .cmi interface, you will get an "inconsistent assumptions about mo= dule Foo" link error (which admittedly would be very confusing, as that usu= ally implies you have stale object files somewhere, not a broken build syst= em).=20 > > I was just floating ideas - if it's actually useful, raise a Mantis PR! >=20 > Will another official bug report or feature request help to improve the > discussed situation? It's just the next step if a change wants to made (or alternately coding up= a suggestion and making a pull request on GitHub). I can certainly see tha= t something along the lines of the -no-cmi option I suggest could be a usef= ul addition, and it's in keeping with options like -impl, -intf and -intf-s= uffix, for example. But I'm just an observer :o) David