> This is pretty much what we do for perl; we run configure and create
> the makefiles and includes.
> 
> Then we check those generated files in and do not regenerate them.
> 
> 

This works fine when there is only a single compiler and there is
no option in the compiler that would require #ifdefs in the headers.

But how do you handle multiple compilers?  How do you handle
compiler options such as use 64 bit?

When headers are generated they represent correct results for
that compiler with that set of options.

We have an important principle that we have adhered to for
the last 20 years, "write once, run everywhere".

The code should not depend on:
1.      The character set (ASCII or EBCDIC).
2.      The code should not depend on the compiler, cc, c89, c99, c+++.
3.      The code should work in multiple locales
4.      The code should avoid #ifdef's for compiler and system
        dependent  features.  #ifdefs are used for functional
        options and testing new features and are not OS specific.
5.      The code should take advantages of services that are only
        on some platforms.

In addition the Makefile themselves are nearly platform and compiler
independent.  (The only exception to this is when a compiler bug
prevents us from enabling optimization for some module.) That is
why we use our own version of make, nmake.
nmake Makefiles are general, concise, scalable, simple to write.
nmake supports multiple directories and has a much better
method of tracking build changes that standard make which
relies only on time stamps.
nmake is far more efficient than make and supports parallelism
on a single processor as well as network parallelism
which can greatly reduce the time to build large (> 10M line)
projects.

nmake also provides rules for packaging and copyright management.
Until recently, nmake was only available by license from Lucent,
but is now part of the AST Toolkit.

Listening to all the constraints that Sun seems to have with
its makefiles, it might be easier to move to nmake.
My experience with UWIN was that it was rather easy to
move from make makefiles to nmake makefiles and the benefits
far outweighed the cost.

David Korn
dgk at research.att.com

Reply via email to