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 A54A97F72A for ; Wed, 10 Aug 2016 10:20:23 +0200 (CEST) IronPort-PHdr: 9a23:FdQGjBH5rDvlancypyGcOJ1GYnF86YWxBRYc798ds5kLTJ74p8+wAkXT6L1XgUPTWs2DsrQf2rOQ6/qrADVQqdbZ6TZZIcQKD0dEwewt3CUYSPafDkP6KPO4JwcbJ+9lEGFfwnegLEJOE9z/bVCB6le77DoVBwmtfVEtfre9JIfegoyN2vyo/NWLOkMT1WP7Oek5dUzm5UWJ749N0NMkcv5wgjLy4VJwM9xMwm1pIV/B1z3d3eyXuKBZziJLpvg6/NRBW6ipN44xTLhfESh0ezttvJ6jnVD5QACO/noRVHkN2loNWlCdrUKyYpCk+C79sfF6xCKyMsj/TLRyUjOnpe8/TRjvkyAbPBY29WjWjop7i6cN8zy7oBkq74fKYY3dHf56ZaTFZZtOSXBIG8BcSDdpB46gZpATBuECe+1fqt+u9BM1sRKiCFz0V6vUwThSiyqzhPVi3g== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=dra-news@metastack.com; spf=Pass smtp.mailfrom=dra-news@metastack.com; spf=None smtp.helo=postmaster@outmail149113.authsmtp.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.149.113; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com designates 62.13.149.113 as permitted sender) identity=mailfrom; client-ip=62.13.149.113; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@outmail149113.authsmtp.com) identity=helo; client-ip=62.13.149.113; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail149113.authsmtp.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADAAB34qpXl3GVDT5dgxiBA3wHpBsGiFiOJSSFeQKBVzwQAQEBAQEBAQERAQEBAQEIFgc9C4IyBAETAYITAQEEATo/EAIBCBgeECERJQIEDgUIEgGHfAMPCQMBCbxzDYQyAQEIAQEBAQEihWKFFYJDgX+DKoIvBYgehzCJOTSGHYYzgjwKgi+NCogth381gjERC4FMbgGGLH8BAQE X-IPAS-Result: A0ADAAB34qpXl3GVDT5dgxiBA3wHpBsGiFiOJSSFeQKBVzwQAQEBAQEBAQERAQEBAQEIFgc9C4IyBAETAYITAQEEATo/EAIBCBgeECERJQIEDgUIEgGHfAMPCQMBCbxzDYQyAQEIAQEBAQEihWKFFYJDgX+DKoIvBYgehzCJOTSGHYYzgjwKgi+NCogth381gjERC4FMbgGGLH8BAQE X-IronPort-AV: E=Sophos;i="5.28,498,1464645600"; d="scan'208";a="187335744" Received: from outmail149113.authsmtp.com ([62.13.149.113]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Aug 2016 10:20:22 +0200 Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt24.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u7A8KKXb044307; Wed, 10 Aug 2016 09:20:20 +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 u7A8KIuN077014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2016 09:20:19 +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 u7A8KHtf025197; Wed, 10 Aug 2016 09:20:17 +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; Wed, 10 Aug 2016 09:20:17 +0100 From: David Allsopp To: "moosotc@gmail.com" CC: Gabriel Scherer , caml users Thread-Topic: [Caml-list] Interface(.mli) location Thread-Index: AQHR8nf2WCvy6CNG7kmmtpBMUxmENKBB1f8g Date: Wed, 10 Aug 2016 08:20:16 +0000 Message-ID: References: <8737mfp7j3.fsf@gmail.com> <87y447npv3.fsf@gmail.com> <87r39znl6m.fsf@gmail.com> <87mvknnia0.fsf@gmail.com> <87k2fqcirv.fsf@gmail.com> <87d1licgmw.fsf@gmail.com> <878tw6cgh2.fsf@gmail.com> <87vaz9bxjq.fsf@gmail.com> <87k2fpbtud.fsf@gmail.com> In-Reply-To: <87k2fpbtud.fsf@gmail.com> 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: 4670e70f-5ed3-11e6-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNl8UURhQ KkJXbgESJgREAnhE VHkJW1VSQF14U2F1 YQtYIwdcYVRPXwB0 UklLXFNTEBpqBAMA SFsZIxEJDkA4eHl3 ZUdmEHFSWUR6O0J7 RU4BEm1QeGI1PGMC UUENcR4GI1cfYx9F a1V+U3VeMGQObjQC Ml17DBs4ODEaLCVO XjRFDFQOTFwFFzUx B1YHGTRuVUkCTCwv LhsgQl4B X-Authentic-SMTP: 61633634383431.1038: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 moosotc@gmail.com wrote: > David Allsopp writes: >=20 > > moosotc@gmail.com wrote: > >> David Allsopp writes: > >> > >> > moosotc@gmail.com wrote: > >> >> moosotc@gmail.com writes: > >> >> > >> >> > moosotc@gmail.com writes: > >> >> > > >> >> >> David Allsopp writes: > >> >> >> > >> >> > [..snip..] > >> >> > > >> >> >>>> > >> >> >>>> d) Make the compiler skip generation of .cmi if it sees one > >> >> >>>> in the > >> -I > >> >> >>>> directories? > >> >> >>> > >> >> >>> No - I think the use-case is too niche to justify breaking > >> >> >>> backwards compatibility. That's potentially a very subtle way > >> >> >>> to break someone else's existing build system. The existing > >> >> >>> behaviour is precisely documented in the manual (even if it's > >> >> >>> not necessarily the best approach). > >> >> >>> > >> >> >> > >> >> >> Original post asked for either change of behavior or > >> >> >> documentation, I failed to find the precise documentation, care > >> >> >> pointing out where exactly things are described in the manual? > >> > > >> > http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec263 > >> > describes how .mli and .ml are handled by the compiler (and when > >> > .cmi is generated or checked against) and the description of -I in > >> > http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec264 > >> > explains that -I only adds search directories for compiled files, > >> > not source files. > >> > >> Thanks, but the manual is completely silent on WHERE it looks for > >> those files. The issue is not trivial as there are 3 options I can > >> readily come up with: > >> a. current working directory > >> b. base directory of -o argument > >> c. a set of -I directories > >> d. directory where file to be compiled lives > >> > >> It looks as if option d. is in effect, but nowhere it is spelled out. > > > > Hmm - to my taste the silence says everything required! Options b and > > c are completely illogical (b would involve inferring an input > > directory from an output directory and option c contradicts something > > the manual does state about what -I means). Option a would be > > surprising behaviour and to my mind is contradicted by the use of "x" > > in italics 8.1 which to me quite reasonably reads as "change the .ml > > to .mli" and so include the directory, if there is one. To expect the > > compiler to look for ./foo.mli when you specified bar/foo.ml would > > mean you'd changed "x". > > >=20 > As outlined in the original message, suppose you have the same interface > but several different implementations (selected during the package > configuration step for instance), let's call the module Mod. >=20 > Under option d. variants (living in different directories) would each have > to carry the _same_ mod.mli file in the container directory just to > satisfy the compilers discovery logic. >=20 > srctree/var1/mod.{ml,mli} > srctree/var2/mod.{ml,mli} >=20 > instead of potential >=20 > srctree/mod.mli srctree/var1/mod.ml srctree/var2/mod.ml Yes, I get that - this is starting to feel mutually recursive. As it concer= ns you hugely, looking again at your original message: a) Yes, the compiler does expect the .ml and .mli files to be in the same d= irectory b) Yes, this behaviour is specified in the manual, possibly too mathematica= lly for your tastes, and perhaps benefitting from a cross-reference/extra s= entence in section 2.5 to the compiler driver's documentation. c) No, the compiler does not force you to put .mli files with the .ml files= in your use case - it has existing tools which can just about facilitate t= he layout you're after (see below). They could be improved, though. d) Lifting the "restriction", for example by allowing -I to search for .mli= files, poses a large backwards-compatibility risk. Of the options I'd already specified, were any of: a) Add a new command line parameter to make ocamlc/ocamlopt pretend that it= found a .mli file with the .ml file (and so use the -I directories to find= the .cmi) b) Abuse the -intf-suffix parameter to achieve the same effect as option a= =20 c) Put a dummy/empty .mli (not the actual one) in each directory to achieve= the same thing fundamentally unsuitable? You did eliminate the fourth option, which was ju= st to delete the auto-generated .cmi file as with -o you can make it overwr= ite the actual .cmi file. I'm still puzzled as to why none of those other o= ptions yields a solution and the only way to you is a breaking change to th= e compiler driver or very pedantic updates to the documentation? David