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

["Gerd Stolpmann" <info@gerd-stolpmann.de>]

> On Mon, Mar 05, 2012 at 11:46:08AM +0100, Gabriel Scherer wrote:
>> 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.
>
> 8K is not much.

I second here, although I never hit the limit on Windows. However,
command-line args of several megabytes are not uncommon for big projects,
especially when you call ocamlc with tons of libraries. Well, I never did
that large projects under Windows, only under Linux.

>> 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.
>
> I stopped using OCaml for new development *because* of the pain it
> caused on MSWIN, so my opinion is probably not very valuable.
>
> It looks to me like you could simply disable the feature for arguments
> following -w.  However, if you want to remove the feature, I suggest
> that you do so in three stages:

I think a very first shot could be to require that the responsefile must
be given as an absolute path (with drive letter, or as network path). This
will syntactically disambiguate it from most other uses. Normally it
points to the temp folder anyway, given as absolute path, so this
additional requirement will hardly break programs.

A cleaner solution would probably to move the responsefile implementation
up to the Arg module, so that the user (a) sees it, and (b) can enable or
disable it as needed.

Gerd

>
>     1.  Disable the @responsefile feature and provide a command line
> 	flag to reenable it.  Warn if this conflicts with the -w @a
> 	style of options.
>     2.  In a later release, remove the code, but make the flag print
> 	an appropriate diagnostic.
>     3.  In an even later release, remove the flag completely.
>
> The time between the first two steps should be determined by the
> response to the first step.
>
> This is the standard evolution: make people notice that you are taking
> a feature away, but let them keep using it, followed by taking it
> away, but telling them it's gone, followed by pretending it never
> existed.
>
> It's good that you're adding the desirable preliminary of asking
> first.
>
>
>     Jeff Schultz
>
> --
> 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
>
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.