Re: [GD-General] Compile times

[brian h. <bri...@py...>]

> I suffered severe compile-time shock when I first started working at
> Oddworld, so I remember timing a build of Soul Ride (my immediate
> prior project) on the machine at work.  Stats:
> 
> full build: ~45 seconds (VC6)
> 1.80M total
> 1.46M .cpp  (94 files)
> 0.15M .c    (19 files)
> 0.18M .h    (88 files)
> (71K lines total)

Then we have very similar build times and sizes for our 
respective "small" projects.  So the question is -- what are the really 
big chunks that "big" project adds that hoses everything?  STL is the 
obvious commonality, because large projects sans STL still seem like 
they compile pretty quickly.
 
> The reason this works is because the compiler only reads headers (and
> builds data structures from them) once for the whole lump.  As opposed
> to reading, building structures, compiling a few hundred lines, and
> then flushing everything out again, once for each source file.  Our
> typical #include line-count is in excess of 25K lines (because of
> STL).

So it would seem that STL is directly the culprit for lots of these 
build time explosions.  
 
> Unfortunately the link time didn't seem to drop any, which is the

Are your codebases built into a single monolithic EXE, or an EXE and 
multiple DLLs?  The latter approach seems to help link times 
appreciably.

> nobody under the age of 30 can be bothered to type "make" :).

Kids these days. =)

Speaking of which, I'm curious if anyone has tried using jam (Just 
Another Make)?  make isn't even quite 80s technology, much less 2000+ 
technology.  It's mind bogglingly obtuse, yet somehow manages to 
survive even today.  jam is an attempt to sort out this mess somewhat 
more cleanly, and Apple has migrated to it for ProjectBuilder.

Brian