major update 08/05/1998
At the request of the nmake Team, HP has implemented support for -I- in their aCC compiler. The Lucent Team provided technical consultation and reviewed HP's work for this feature, and we would like to thank HP for their cooperation and hard work in implementing this for us.
With this new feature nmake cpp is not needed when using aCC (see the nmake cpp faq for more information.) If you are having problems using aCC check to see if your version supports -I-. We strongly recommend using versions of aCC with -I- support, this will eliminate a lot of problems users have when using aCC with nmake.
$ what /opt/aCC/bin/aCC /opt/aCC/bin/aCC: HP aC++ B3910B A.03.10 HP aC++ B3910B A.03.04 (970930) Support Library
$ what /opt/aCC/bin/aCC /opt/aCC/bin/aCC: HP aC++ B3910B A.01.12 HP aC++ B3910B A.01.01 Support Library
$ probe -k C make aCC $ probe -k C pp aCC
$ probe C make aCC $ probe C pp aCC
$ probe -l C make aCC
The following information was put together before aCC supported -I- and all below references to aCC imply this older version. This information will be left here for those who have been unable to upgrade, but we do strongly recommend everyone using aCC upgrade to the latest version with -I- support.
The HP Softbench compiler (sometimes called aCC, check if aCC is linked to CC) Version A.01.05 introduced a new method for template instantiation, compile-time instantiation. When this option is in effect (which it is by default), nmake cpp works and provides correct viewpathing for #include "..." files. To get this to work, you need to modify the probe/C/pp so the include pragmas read:
#pragma pp:include "/opt/aCC/include" #pragma pp:include "/opt/aCC/include/iostream" #pragma pp:include "/usr" #pragma pp:include "/usr/include"
The probe/C/make file should be modified to include the following for CC.STDINCLUDE:
CC.STDINCLUDE = /opt/aCC/include \ /opt/aCC/include/iostream \ /usr \ /usr/include
You also need to include -D-L in CCFLAGS:
CCFLAGS = -D-L
We plan to extend probe so that aCC works automatically with nmake in the case of compile-time instantiation.
There is a bigger issue when using the HP Softbench aCC (check if CC is linked to aCC) compiler with nmake when using the compiler's link-time instantiation.
To fully understand the problem you might first want to see why nmake comes with its own cpp.
The problems arise when the compiler is recursively invoked during link-time instantiation. The first problem is that, since aCC does not accept an alternate cpp, nmake uses a shell wrapper (ppcc) that preprocesses the program to create a .i file, calls aCC to compile the .i file, and then deletes the .i file. At link time aCC is called with the .i file as argument. This call fails because the .i file no longer exists. The second problem is that, even if we could get aCC to be called with the original .c file instead of the .i file as an argument, we have no way to cause nmake cpp to be called in to properly preprocess the file.
The only workaround at this time is to use the native preprocessor instead of nmake cpp, and to have all source code in the same VPATH node, or use compile-time instantiation as described above. [Note: HP has made compile-time instantiation the default mode and is now recommending its use.]
If you must use aCC's link-time instantiation this is how to use it with nmake:
Warning: It seems some projects have "fixed" this problem by modifying the make probe file for this compiler and adding -I- to the CC.DIALECT setting. Yes, if you do this the compile errors will go away, but this has the exact same affect as setting nativepp=-1! You are just telling nmake the native preprocessor supports viewpathing and the -I- argument, which it doesn't. When nmake sees this it uses the native preprocessor instead of its own. So don't fool yourself into thinking you've fixed anything. It is safer to use nativepp, understand the issues, and do not use viewpathing.