From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q25Aks3C019856 for ; Mon, 5 Mar 2012 11:46:54 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEBAP+YVE9KfVIqimdsb2JhbAApGrROCCIBAQEKCQ0HEgYjghYCLAEbHgMSEF0BEQEFAQ4BExsMDodlCymfFYJdCotygnGEVj+BDAEFC4oMhkYElT6HG4cZPYQFgVQ X-IronPort-AV: E=Sophos;i="4.73,533,1325458800"; d="scan'208";a="134395377" Received: from mail-ww0-f42.google.com ([74.125.82.42]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Mar 2012 11:46:49 +0100 Received: by wgbds11 with SMTP id ds11so1142543wgb.3 for ; Mon, 05 Mar 2012 02:46:48 -0800 (PST) Received-SPF: pass (google.com: domain of gabriel.scherer@gmail.com designates 10.216.134.2 as permitted sender) client-ip=10.216.134.2; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gabriel.scherer@gmail.com designates 10.216.134.2 as permitted sender) smtp.mail=gabriel.scherer@gmail.com; dkim=pass header.i=gabriel.scherer@gmail.com Received: from mr.google.com ([10.216.134.2]) by 10.216.134.2 with SMTP id r2mr1070472wei.31.1330944408699 (num_hops = 1); Mon, 05 Mar 2012 02:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=rK4ipJtTGUcZd0rQZU3WZuG1Ur1dWnd+HeXKAjPcJRc=; b=yIm3iO/QKxwNBMhQ622b7bTPtBWSVFqGFYRxq6HeOF8+PnX4hBckKz/vyYbrk6OCk4 32/gH6kVxt2/SwaxCPYLbEvHzVLu6YzFeqUpxV++5hVlPs2dl57SR3Hx8zTMaBWraxzC PuWeztE5Fcgr6Xz3dsRsHHQNF+TSnnruNfWHWNz8ddB0uSsuEtOm7/22kZAwFt8W+Z6/ MjcETR8erS+o1zOUpM/Jd5Z9rKYqNairn95nmYyVdsD1QtsLNB5GJ6eULiYII1u73/gx AvoGCan5qsozaj73xHzHoFvugFtHZSFFHsz4OzA0bh8831r0dok1ejuhIsaOa3kUpdtX 7mDw== Received: by 10.216.134.2 with SMTP id r2mr838163wei.31.1330944408443; Mon, 05 Mar 2012 02:46:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.200.85 with HTTP; Mon, 5 Mar 2012 02:46:08 -0800 (PST) From: Gabriel Scherer Date: Mon, 5 Mar 2012 11:46:08 +0100 Message-ID: To: caml-list caml-list Content-Type: text/plain; charset=ISO-8859-1 Subject: [Caml-list] [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature? In the process of discussing bug #5312, the caml team would like to know if people still have use of the @responsefile feature under windows. If not, it could be removed from the runtime -- that is from all OCaml programs. http://caml.inria.fr/mantis/view.php?id=5312 @responsefile is a feature/convention under Windows to provide files containing command-line argument options; when a tool parses command-line options and encounters a file name prefixed by a '@' character, it expands its contents as if it were part of the command-line invocation. This is used to circumvent the historically fairly ridiculous limit on command-line length in the old 'cmd.com'. The OCaml toolchain copes with @responsefile in two places -- as far as I know, but I'm not familiar with anything Windows. First, when the compiler invokes external tools (linkers, etc.) under Windows, it uses a @responsefile if the command-line length exceeds a fixed limit -- curently 4096, used to be 256 and annoy users. Second, under Windows only, the OCaml runtime considers @-prefixed arguments as responsefile file names, and expands them during its initialization phase. This is silently done by the OCaml *runtime*, so all OCaml programs are affected; the compilers, but also the user programs. Did you know that you shouldn't use '@' in your command-line parameters syntax if you want your program to work on Windows? The first use has been problematic in the past because some of the underlying toolchains (Cygwin, mingw...) did not support @responsefiles. The second case is now problematic as the @-syntax conflicts with the warning-as-error syntax of the compiler: as reported by Dmitry Grebeniuk, "-w @a" under windows complains about a missing file "a", while it really should mark all warnings as errors -- a very bad idea for future compatibility when new warnings are added, by the way; don't use that in released OCaml software. According to our Windows spies, the command-line restrictions are nowadays very reasonable: 8K for cmd.com, and 32K internally. Maybe the @responsefile feature has outlived its use, and this bug could be fixed by simply removing the @-files expansion phase of the runtime. This change would however affect all user programs, so it should not be taken lightly; it could break your programs. What do OCaml Windows user think? Do you still rely on @reponsefile? Please complain if you do -- or your users do -- and don't hesitate to pass the question to off-list OCaml Windows users. Some links: - previous angry discussions about @responsefile: http://caml.inria.fr/mantis/view.php?id=1877 http://caml.inria.fr/pub/ml-archives/caml-list/2001/04/ba5a929cb6f14c1148929855a9b55765.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2007/08/a3cee429c9fe0dd9181975bc1d44b777.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2007/08/2e8f9b99ab8c61568b09ce28b5c27cc1.en.html - documentation about the compiler warning options: http://caml.inria.fr/pub/docs/manual-ocaml/manual022.html - a warning against using "-warn a -warn-error a" -- unrelated, but can't hurt http://caml.inria.fr/pub/ml-archives/caml-list/2009/11/91883440c8a0481a4233758946e5c3bf.en.html