From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 BE06F801BE for ; Sun, 9 Jul 2017 17:00:56 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.40,334,1496095200"; d="asc'?scan'208";a="230983169" Received: from lfbn-1-12092-138.w90-92.abo.wanadoo.fr (HELO mocuter) ([90.92.151.138]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2017 17:00:56 +0200 Received: by mocuter (Postfix, from userid 501) id 58FBC264389B; Sun, 9 Jul 2017 17:00:54 +0200 (CEST) Date: Sun, 9 Jul 2017 17:00:54 +0200 From: Timothy Bourke To: David Allsopp Cc: caml-list@inria.fr Message-ID: <20170709150054.vcpwe26fr46khgec@xocuter.home> Mail-Followup-To: David Allsopp , caml-list@inria.fr References: <20170708140810.vpglvvttlfbflus4@xocuter.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2gafsjqlv7gbj5pu" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.tbrk.org/pubkey.txt User-Agent: NeoMutt/20170609 (1.8.3) X-Validation-by: timothy.bourke@inria.fr Subject: Re: [Caml-list] ocamlc 4.03 -> 4.04: change in meaning of -i --2gafsjqlv7gbj5pu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks for your response. * David Allsopp [2017-07-09 09:47 +0000]: > Timothy Bourke wrote: > > Is this change in behaviour intentional? >=20 > This behaviour is a consequence of GPR#464 (in particular https://github.= com/ocaml/ocaml/commit/4dc3efe) and intentional. That commit message is indeed quite clear. I got lost in the other=20 ones that were more concerned with .c files. =20 > Prior to 4.04.0, at the point of processing a.ml in `ocamlc a.ml -i b.ml`= the compiler assumes it is linking (since that is the default operation) a= nd so generates a.cmo and a.cmi. Once it sees the `-i` it discovers that it= 's supposed to be dumping interfaces and so prints the interface of b.ml - = this works because by fluke it compiled a.ml previously. Prior to 4.04.0, i= f instead you had run `ocamlc -i a.ml b.ml` (with no a.cmi built) you would= have got the same error and the same output. I wouldn't have said that it worked by fluke. This design seemed=20 reasonable to me (since the order of files is already significant),=20 though I admit that it's "trickier" than the new approach. =20 > PR#6475/GPR#464 took the decision that the command line arguments should = be fully interpreted before doing anything, hence in 4.04.0+ `ocamlc a.ml -= i b.ml` and `ocamlc -i a.ml b.ml` are the same command and interpreted as t= he latter (the change is marked as breaking as a result). OK. Well, I will have to rethink my tool then. To give a bit more background, the problem concerns the checklistings=20 LaTeX package (https://www.ctan.org/pkg/checklistings) which allows=20 for compiling code snippets extracted from LaTeX documents. For OCaml=20 listings, it is normal to pass the -i option so that the types=20 inferred for a code snippet can be displayed in a document. It is also=20 normal for later code snippets to depend on earlier ones. The -i=20 option, however, does not generate the .cmi file required to compile=20 later snippets. My solution was thus to rely on the previous behaviour=20 of ocamlc. Would it be reasonable to have a means of both compiling and showing=20 the inferred types? For instance, by passing both -c and -i? Tim. --2gafsjqlv7gbj5pu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE3GWV8Ve1AMz4ZV8OHQga2C8a110FAlliRSQACgkQHQga2C8a 113AQAgAo34uLyupUqdva2NPgTy5S6qy/3Oo4UiLNraWIh1NOzZ14IGkyvkK+OYy 0iYbxrXwSShHu52T66NfVEF00AFfSI7ZozjdJVHzf00zRddnMkmxVu5GQplFfWdg WpwdSfR1xb4g4guqRKCbmbWDJ9zVhRT4NSFwwn1mEwrE/q2O0FVRJNqISGCxDLw7 nCOhVtJTgHXG8y30P4pu96UO00SwgL5NRRQZlEfm4j3RCOLzoxVI6V8v+uAyZSTj L6khTX5YxF42aZwoAe1F4Mt+GzEQ44/vyH+hMrrFlrelwmkWsnqcy9lCZk2OcY48 cKyEKwbljDPY2qzfE/sAbT2BEdpmoA== =4zgu -----END PGP SIGNATURE----- --2gafsjqlv7gbj5pu--