Build system woes

[Roman Leshchinskiy]

On 30/07/2008, at 23:46, Simon Marlow wrote:

> We can talk about the general issues on IRC.  But I thought I'd  
> answer a few of the specific questions quickly:

Thanks, Simon!

> Roman Leschinskiy wrote:
>
>> I don't think I understand how GHC itself is built any longer,  
>> either. What does cabal-bin do?
>
> It's effectively a pre-compiled Setup.hs for packages that have no  
> need for a custom Setup.hs.  cabal-install does the same job for end- 
> users, but we can't rely on having cabal-install in the GHC build  
> system.

I see. So it looks at the Build-Type in the package description and  
calls the right defaultMain if it's not Custom. And if my Setup.hs  
isn't standard then it's my responsibility to set the Build-Type to  
Custom in the .cabal file and this isn't checked, right?

I wonder, though. What exactly does this buy us? Duncan says:

> The point being that linking default Setup.hs scripts all the time  
> is a
> waste (especially since it doesn't parallelise).

But the time spent in compiling those Setup.hs is negligible and don't  
understand the "it doesn't parallelise" bit.

>> What is runghc.wrapper?
>
> it's a template used to make a shell wrapper for a binary.  There  
> seems to be new functionality in Cabal to support this.

I see. Is runghc the only program we do this for? Or will others be  
added gradually?

>> What is the difference between make.library.* and build.library.*  
>> and why do we need both
>
> This one is my fault. build.* runs 'cabal-bin build', whereas make.*  
> runs 'cabal-bin makefile' followed by 'make'.  That is, build.* ends  
> up using ghc --make, whereas make.* ends up using a traditional  
> makefile with ghc -M for dependencies and individual single-module  
> compilations.  The latter was added so that we could (a) use make -j  
> and (b) compile single modules for testing/debugging purposes.

Ok, this answers the following question:

> > (and why doesn't one of them work for dph)?

Because it does non-standard stuff in Setup.hs and hence no Makefile  
can be generated. Hence the SUBDIRS_BUILD hackery in libraries/ 
Makefile, I assume.

Thanks again!

Roman