In an effort to keep more in touch with you, our customers, and inform you of the latest happenings with our product we will be publishing quarterly newsletters (via the web).
The format of the newsletters will be relatively the same in future issues. The team aims to inform you of the product's direction and technical usage in a brief and concise manner and as such the newsletter will not be lengthy. Each newsletter will at the minimum contain a highlight of the quarter along with some nmake usage we believe will be beneficial to the nmake community. We will discuss technical issues and ask our customers for suggestions of things they would like to see in nmake.
As the newsletters will be available over the web, feel free to save this URL in your browser's bookmark and even to pass it on to nmake customers you know who may not be aware of our newsletters.
Thanks goes out to everyone who participated in the 1998 CVA survey! We will be analyzing the data and reporting on it in a later issue. A big congratulations goes out to our 6 winners from the survey drawing! Each winner received a Lucent World travel alarm clock. The winners are:
- Ann Wittneben
- Alan Pepperman
- James Parker
- Gene Walli
- Dana McCready
- Brendan Cain
All versions of nmake beyond 3.0 are considered year 2000 safe, they do not need code changes to support the year 2000. However they were originally compiled on non-Y2K-compliant versions of each vendor's operating system. To address this issue we have rebuilt 3.1.2 on Y2K-compliant versions of the operating systems. The year 2000 version of nmake 3.1.2 is the only version of nmake that is specifically compiled and certified on the Y2K-compliant OS versions available for each architecture. Earlier versions of nmake are not supported on Y2K-compliant operating systems so by the year 2000 everyone must be running the Y2K build of nmake 3.1.2.
New nmake manuals are scheduled to be released in September 1998. The old nmake 3.0 manual has been split into two documents and rewritten to reflect nmake 3.1.2. The new set will consist of an nmake Reference Manual and an nmake User's Guide. Once released they will be available for download from the nmake manual web page; there will be no hard-copies available. Keep your eyes open, or wait for their availability announcement in the next newsletter.
We are starting to collect feedback for technical support on a per issue basis. That is, for each technical support issue our customers open with the helpdesk we would like the customer to fill out a short survey (4 multiple-choice and 2 text questions) when the issue is resolved. The survey data will allow us to track our quality and help us make on-going improvements to better serve the nmake users.
In the beginning the survey is only available to internal Lucent customers over the web. When an issue is resolved we will ask the customer to visit the survey page and submit the form. Later we plan to offer the survey to external customers via email feedback.
At the request of the nmake Team, HP has implemented support for -I- in their aCC compiler. The 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 native support for -I- nmake's preprocessor is not needed. The -I- argument provides viewpathing functionality for include files and is the only reason nmake provides a preprocessor. We strongly recommend everyone using aCC to upgrade to the latest version, this will clear up many issues people have when using aCC with nmake.
For more information visit our nmake aCC faq. You will find information regarding what version of aCC supports -I- as well as how to incorporate your aCC upgrade into your nmake environment.
No -I- for Sun
We have also contacted Sun about supporting -I- in their Sparcworks C++ compiler but they require payment for the work rather than implementing it on "good faith" as HP did. This is unfortunate as it would resolve a lot of issues that pop up when using nmake cpp with the Solaris C++ compiler. We hope if enough requests are submitted to Sun they will change their minds as we are still willing to work with them to implement this feature.
--A call for comments and feedback
During execution, shell action blocks triggered by nmake send data to their standard output and standard error streams. This information appears as it is generated, allowing real time build process monitoring. However, as a performance enhancement feature, nmake can be configured to allow concurrent and distributed execution of shell action blocks (to the extent possible given rule dependencies). However, when nmake is configured to run more than one shell action block concurrently, the standard output and standard error of concurrently executing action blocks may intermingle, causing build output logs to become very difficult or impossible to interpret. This problem is known as the "output serialization problem", and is severe enough to discourage use of the nmake concurrent execution features.
The solution we are proposing uses an enclosing shell to capture the top-level output. So, you would say:
nmake_log [nmake options]
The serialized output would appear in $makelog (default makelog) and real-time output would appear in $rmakelog (default rmakelog). In the serialized output log, output related to each triggered action would be kept together. Additionally, in the case of recursive nmake invocations, output related to each recursive nmake invocation will be kept together. The real-time log would contain the output of nmake and triggered actions in the order they actually occur, and would be useful for real-time build monitoring. This output would also appear on the standard output as it occurs.
The Lucent C++ 5.0 compiler is now in beta test. The nmake and C++ teams are working together to iron out any issues when using this new C++ release with nmake. For more information about C++ 5.0, including the new feature lists, see Issue 28 and Issue 27 of the C++ Newsletter (update: C++ newsletters are no longer available).
This tidbit explains how to add generated files to the clobber common action. In our example we generate a .c file from a .d file. It is necessary to expand the clobber common action because the .d -> .c metarule must be given the .TERMINAL attribute in order for the metarule to be included in list of possible metarules to generate a .c file. This is because the .c file itself is given the .TERMINAL attribute from the double-colon operator, thus the meta-rule must also use the .TERMINAL attribute. The .TERMINAL causes the .c file to be regarded as a terminal file, not a generated file, and thus it will not be clobbered by default.
The following example adds the .c file to the list of generated files to be removed for the clobber common action.
/* ---------- begin Makefile ---------- */ .RETAIN : .CLOBBER. %.c : %.d .TERMINAL .CLOBBER.ADD cp $(>) $(<) .CLOBBER.ADD : .MAKE .FORCE .REPEAT .VIRTUAL .ALWAYS .AFTER .CLOBBER. += $(<<) foo :: foo.c /* ---------- end Makefile ---------- */ $ nmake + cp foo.d foo.c + ppcc -i /tools/nmake/sparc5/v3.1.1/lib/cpp cc -O -I-D/tools/nmake/spar c5/v3.1.1/lib/probe/C/pp/BFE0A4FEobincc -I- -c foo.c + ppcc -i /tools/nmake/sparc5/v3.1.1/lib/cpp cc -O -o foo foo.o $ nmake clobber + ignore rm -f foo.c foo.o Makefile.mo Makefile.ms foo
In order to use an nmake reserved word as a target quotes must be put around the target name. The following example shows how to use the reserved word "rules" as a target. This technique may be applied to any reserved word.
/* ---------- begin Makefile ---------- */ /* * Put quotes around rules target - it's a reserved word */ "rules" :: rules.c /* ---------- end Makefile ---------- */ $ nmake + ppcc -i /tools/nmake/sparc5/v3.1.2/lib/cpp cc -O -I-D/tools/nmake/spar c5/v3.1.2/lib/probe/C/pp/D586199Dobincc -I- -c rules.c + ppcc -i /tools/nmake/sparc5/v3.1.2/lib/cpp cc -O -o rules rules.o
We are looking for feedback! Let us know what you think of the newsletter, how we may improve, or ideas you have for future issues. Send us a note at firstname.lastname@example.org. All ideas, suggestions, and comments are welcome.