[GHC] #910: --make should have a -j flag for parallel building

[GHC]

#910: --make should have a -j flag for parallel building
-------------------------------------+------------------------------------
        Reporter:  igloo             |            Owner:
            Type:  feature request   |           Status:  patch
        Priority:  normal            |        Milestone:  _|_
       Component:  Compiler          |          Version:  6.4.2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:  N/A               |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by parcs):

 nh2: That's an interesting idea. We would just have to persist the timing
 information somehow (through the interface file maybe) and implement a
 smart semaphore (replacing QSem) that wakes up the module that would
 result in the shortest compile time. It certainly ''sounds'' possible, at
 least.

 Simon: Import loops were indeed not handled correctly. I managed to work
 out a solution that I hope is understandable. It involves augmenting a
 module's explicit textual dependencies with the implicit dependencies that
 arise from module loops. Let me know what you think.

 Other changes I made:

 1. removed the `BinIO` constructor as suggested
 2. more thoroughly commented the `FastString` implementation, as
 suggested.
 3. revised one of the thread-safety changes: originally, I changed
 `newUnique` and `newUniqueSupply` to atomically update the `env_us` var.
 But the only reason this was necessary is because the `env_us` var was
 shared among interleaved threads created by `forkM`. So instead of making
 sure to atomically update this var, I think it is more sensible to not
 share the `env_us` var among interleaved threads. This solution should be
 in theory more efficient as well, as multiple threads are no longer
 potentially contending on the same `env_us` var.
 4. and I enabled buffering of stdout/stderr when compiling modules via
 GHCi

 Please perform a second pass on all the commits, as I did a lot of
 rebasings and fixups etc and I might have missed something stupid.

 I have not yet fixed the IO manager bug.

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