[GHC] #10791: Add a --disable-large-memory-space configure option

[GHC]

#10791: Add a --disable-large-memory-space configure option
-------------------------------------+-------------------------------------
        Reporter:  erikd             |                Owner:  erikd
            Type:  feature request   |               Status:  closed
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Build System      |              Version:  7.11
      Resolution:  fixed             |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1170
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ericson2314):

 This code is very hard to read, and the behavior very hard to intuit.

  - Folding together the `=yes` and no-flag case *outside* the
 `"$ac_cv_sizeof_void_p" -eq 8` branch falsely implies the default is
 unconditionally/constantly true.

  - `=yes` will be silently ignored on non-Darwin if the test doesn't pass.

  - Ignoring `--enable/disable-large-address-space` on 32-bit is more
 harmful than helpful. The fact is, most (all?) people blindly cargo cult
 and copy paste configure flags, and this will give them a false intuition.
 (Postel's law hurts us by hiding bugs with gratuitous complexity.)
 Crucially and unlike many such similar things, it's not necessary for
 backwards compatibility since this flag is new.

 Granted, I could be persuaded on the 3rd point that on 32-bit the large
 and small address spaces both morally exist but are the same, rather than
 the large one not existing, so the laxer handling of the flags is
 justified. But, at the very least a warning is due on the
 ignored/superfluous flags, and the code restructured to properly separate
 sanitizing user input, checking whether expectations are met, and
 providing a default value.

 Sorry to lash out on random 3 year old issue, but this is a perfect
 example of the sort of "diff golf" / incremental change that leads to
 impenetrable and every-growing configure scripts (or build systems in
 general). 5 minutes of what might seem silly OCD by the original author
 cleaning up what's there can save far more time for the next person. And
 in fact, writing a truth table a is great first step, without which I
 would have spent longer being confused.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler