In base-4.12 we added some response file related utilities -- a
function 'getArgsWithResponseFiles' which enabled users to parse
command line arguments supplied via response files. However, RTS
options contained in such a file were not handled correctly.
When we pass options over the command line, they are first inspected
by the RTS. It separates out the options contained in +RTS...-RTS blocks
and updates the runtime configuration with the supplied values.
There are some other subtleties which must also be dealt with:
(1) If the program is compiled to ignore RTS options, and the user
tries to supply them at runtime, an error should be reported. A lot
variations on this are possible by setting -rtsopts to different
(2) If a program accepts RTS options, they are filtered out from
the value returned by 'getArgs'.
(3) --RTS should disable further processing of arguments by the RTS.
And none of these things are done for the options supplied via
response files. Right now, 'getArgsWithResponseFiles'
processes the response files, instead of the RTS. It iterates over the
list returned by 'getArgs', and issues readFile's for appropriate
elements (the ones that start with '@'). This means that the RTS never
sees any of the options contained in these files, and hence is not
able to process them correctly.
This patch moves the response file processing logic into the
RTS, puts it behind a flag 'expand-response-files'.
If the flag is ON:
- The RTS expands response files
- getArgsWithResponseFiles and getArgs behave the same, and return the command line arguments after expanding response files and removing RTS flags.
- The RTS does not expand response files
- getArgs works in the usual way (doesn't expand response files, and filters RTS flags passed over the command line).
- getArgsWithResponseFiles expands response files, but doesn't process the RTS flags contained in a file.