Re: [Caml-list] [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature?

["Damien Guichard" <alphablock@orange.fr>]

Hello gasche,

Actually i didn't even known about the @responsefile feature.
My ocaml 3.12.1 console programs still run under Windows98se, Win98 can no
more compile yet it can run.
So ocaml windows support is quite long-term.
 
I don't mind whether the @responsefile feature is removed or not.
I won't be affected.  

Thanks for the consideration,

- Damien Guichard (SpiceGuid)


Le 05/03/2012 à 11:46:08, Gabriel Scherer <gabriel.scherer@gmail.com> à écrit
:
>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
>
>-- 
>Caml-list mailing list.  Subscription management and archives:
>https://sympa-roc.inria.fr/wws/info/caml-list
>Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>Bug reports: http://caml.inria.fr/bin/caml-bugs
>