🚀 go-pugleaf

Phil Edwards (pedwards@valhalla.cs.wright.edu) wrote:
: it seems Pieter Hintjens (pahint@eunet.be) sez:
: + I am building the ultimate Universal Header File.  :-)

: I did something similar on a smaller scale.  Compilation of even
: the small programs took forever.  I went back and commented out
: the #include statements which I knew weren't being used.  The
: speedup was *significant*, and I say that running Digital Unix on
: a DEC Alpha 4000.

: What I had been seeing -- but not reading -- for years finally
: sank in after that experience:  more often than not, the most
: expensive (timewise) step in compilation is processing of header
: files.  What you have in mind may be great for those platforms
: which support preprocessed header files, with the result of the
: preprocessing being stored in some intermediate state in a local
: directory with the rest of the source, but for typical platforms
: which process the same file again and again -- sorry, but I'd
: hate to use anything that massive.

When I started with this 'universal header file' the motivation was
to let me edit and compile my code on a PC, with Borland's fast tools
and their pop-up help.  Once I had a 'clean' source I could recompile
and test on the UNIX.

This still stands.  On my cheap pentium, Turbo-C is *fast*.  Even
with all the include's.  The total time I spend compiling is much
less than if I worked only on a UNIX, with a many fewer include's.

Sure, I can't really test my code, but I tyep baldy^H^H^H^H^H^Htype
badly, and I save a lot of time by editing and proof-compiling on
the platform of choice.

Okay, point taken about including masses of files: I am making the
UIF smarter, so that you can tune it with a few #define's at the
start of your program.

Anyone interested in following this project, drop me a line. 
--
Pieter A. Hintjens