#15732: getArgsWithResponseFiles does not filter out RTS options -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13896 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): There's a bigger problem here wrt setting RTS flags via a file. In the current implementation, {{{getArgsWithResponseFiles}}} is responsible for for reading any command-line arguments passed via a file. 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 flags contained in these files. This is fine for regular command-line arguments -- those which are used by a program, not GHC. But if a file contains any RTS flags ({{{+RTS ... -RTS}}}) they're completely ignored since {{{getArgsWithResponseFiles}}} doesn't know what to do with them. But these flags are indeed special, and we want the RTS to know about them. I can think of two ways to fix this: (1) Properly support response files Like all the other arguments, the RTS would also process response files (read, check errors etc.). It can then do the right thing for the flags contained in these files. We'd also like the main GHC executable to support response files (see #15072). (2) Ignore the {{{+RTS ... -RTS}}} flags contained in a response file Such flags won't have any effect on the RTS. {{{getArgsWithResponseFiles}}} would just filter these out from it's return value. Option (2) is very easy to implement but I don't feel like it's the right thing to do. I can imagine this causing confusion and further problems. On the other hand, (1) is a big change which might affect things included in the Haskell Report. If we decide to go with option (1), I'd be happy to give it a shot. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15732#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler