Overview of new make features since 10/01/87.

(*) In general, the make interface has been changed in order to present

a consistent model for the make programmer and make user.

(*) if, while and for programming constructs added. This cleans up

the rules specifications and lightens the overload on the $(...)

expansion operators.

(*) Makefiles preprocessed with new ANSI cpp in passthrough mode.

This allows full use of #if and #include directives without the

interaction between Makefile text and macro expansion.

(*) All compiled C source files are passed through the new ANSI cpp

in (Reiser) compatibility mode to insure proper interaction

between the make and cpp include file search rules.

(*) Statefile interface reworked to minimize state information

conflicts with Makefile information. Prerequisite list and

action changes are also detected.

(*) More languages added to the implicit file dependency scanner:

C, fortran, BSD fortran, ratfor, m4 and [nt]roff. Additional

languages are added by adding a table entry and one new text

scan function to the make executable. There is also support

for a separate external implicit dependency scan program,

although none have been written yet.

(*) State variable dependencies are automatically generated by

adding the variable names to the prerequisites of .STATE.

(*) $(...) expansion operator algorithm cleaned up to apply operators

from left to right, allowing multiple occurrences of an operator

within a single expansion.

(*) VPATH and less restricted MAKEPATH are now supported.

(VPATH has been in the LC version since around 01/86.)

(*) New attributes added to allow finer control in the rule

specification language.

(*) Support for remote file systems added, including workarounds

for the RFS time skew botch where the inode time stamps of a file

can change even though the file has not been touched.

Inconsistencies between the local and remote (file system) clocks

are also detected and handled.

(*) More operators have been added, some support the install action,

some support recursive makes and another allows a single

action to generate more than one target.

(*) Explicit and implicit prerequisites that are generated by

other actions are now properly handled.

(*) `local var ...' added to declare local variables for .MAKE actions.

(*) .FUNCTIONAL added to cause a target to be made whenever a

variable by the same name is expanded (using $(...)).

(*) .RETAIN marks variables with value to be retained in state file.

(*) Action concurrency reimplemented to properly disassociate

independent actions.

Work is underway to transfer this latest version of nmake to LC.

Beta testing should start by April 1988.

Overview of new C preprocessor features.

(*) The preprocessor is centered around the libpp.a library. This

library provides a tokenizing implementation of the preprocessing

stages of ANSI standard C. The same library is used to construct

a standalone prepreprocessor as well as a C compiler front end

that, compiled with the library, eliminates the need for a

separate preprocessing pass. Other C tools requiring C tokenizing

can use this library, providing a common interface to C language

tokens.

(*) The #pragma interface is exploited to allow the addition of new

directives and #pragma's without changing the preprocessor

executable. Most implementation details can be specified by

directives in the file "ppdefault.h" that is automatically included

(by the standalone cpp library wrapper) as an initialization step.

(*) #assert, #unassert and corresponding #if predicate tests have been

added to relieve the conflicts introduced by predefined #define

macros (e.g., unix, vax, u3b, ...). This is the same feature

present in the extended Reiser cpp that has been included in the

nmake distribution for the past two years.

(*) The implementation is sensitive to the incompatible differences

between the Reiser cpp (used by AT&T and BSD compilers) and the new

ANSI standard C. A compatibility dialect implements Reiser

features, allowing for a smooth transition to the ANSI standard.

(*) To aid in the transition to ANSI, the preprocessor can do some

operations that would normally be done by the lexical analysis

stage of a compiler front end:

(*) convert new-style character constants to a form

recognized by all current compilers

(*) concatenate adjacent string literals

(*) The preprocessor can also warn about obsolete constructs used

in the compatibility dialect and on non-standard constructs

used in the ANSI dialect. The latter is useful in writing

C code that is made to run through other implementations of

ANSI standard C.

(*) The preprocessor allows a C language implementor to take

advantage of local extensions without invalidating the

conformance of the C language implementation.

(*) Checkpointing of preprocessed header files is supported.

Checkpointing can save appreciable amounts of preprocess

time in projects where the components share a large subset

of header files.

I have been in contact with Steve Adamski, the person responsible

for cpp at SF, since work began on the new cpp in December 1986.

Some new cpp features have influenced decisions made at Summit

(they are adopting #assert in the next release) and have also

influenced the wording of the draft proposed ANSI C standard

(errors were found in the standard's macro expansion algorithm,

as well as its treatment of invalid preprocessing tokens).