The crew is putting together the next release, lu3.4, due out in June 2001. In addition to several fixes this release will include the following new features and enhancements. We'll send a note out to our mailing list when the release is available, or you can keep an eye on the web site. In the next issue we'll discuss some new features in more detail.
- Introduction of new dependency-based Java build support
- Probe hints (mentioned in issue 5)
- Improved support for Sun WorkShopTM 6 C++ compiler
- Support for C++ implicit includes
- cc-% support for adding flags to CCFLAGS
- Scoped CCFLAGS for :: operator
We are considering dropping support for HP-UX 10.10, which is no longer supported by HP. We would continue to support HP-UX 10.20 (and above) and HP-UX 11.x. New releases as well as patches on older releases would not be available for HP-UX 10.10. We would, however, continue to provide technical help to users on HP-UX 10.10.
If you have any concerns about the lack of support for HP-UX 10.10 please let us know. Any feedback we receive will help us gauge the impact to our users so we can make an informed decision.
If you are a user of HP's aCC compiler then you should already know that aCC has native support for the -I- feature. An user recently contacted us having trouble including a particular header with this compiler. They had a special need to specify the full path to a header file (a work-around provided by a 3rd party vendor) but aCC would not pick up the header if -I- was used.
For example, the following type of include directive:
results in the following error:
$ /opt/aCC/bin/aCC -I- -c test.c Error 112: "test.c", line 2 # Include file </usr/include/stdio.h> not found. #include </usr/include/stdio.h> ^^^^^^^^^^^^^^^^^^^^^^
To get the include statement to work with -I- a -I/ flag must be added to the command line.
$ /opt/aCC/bin/aCC -I- -I/ -c test.c
To do this from nmake it will be easiest to insert the -I/ flag in front of the -I- by simply using CCFLAGS. However this will require the header be included with quotes instead of brackets. So to get around this with nmake change the include statement to use quotes:
and set CCFLAGS as follows in your makefile:
CCFLAGS += -I/
We have contacted HP about this since files included using the full path should not be bound to the -I flags on the compile line.
It is fairly common for new nmake users to wonder why their rules do not find files in the viewpath. The common thought is that nmake viewpaths automatically, so files referenced inside an action block should be found in the viewpath. But this is not true. The action block is sent to the shell for execution, nmake is not aware of its contents. The only thing nmake does is expand any nmake variables before sending the block to the shell.
The trick to viewpathing is the use of nmake's automatic variables within your rules. If you are writing rules you should be familiar with the following automatic variables at a minimum:
- $(<) - the current target
- $(>) - explicit file prerequisites which are out-of-date
- $(*) - all explicit file prerequisites
Here is a simple example that will not work in the viewpath:
FILES = abc xyz targ1 : $(FILES) cat $(FILES) > targ1
In this case $(FILES) in the action block will expand to "abc xyz" so the shell will expect to find them in the current directory. If one is down the viewpath an error will occur. The makefile should be rewritten as follows:
FILES = abc xyz targ1 : $(FILES) cat $(*) > $(<)
Now $(*) will be expanded to include the paths to the prerequisite files abc and xyz. A file down the viewpath will be expanded to its full path, a file in the current directory will be expanded to only the filename. This allows the cat command to access both files regardless of where they are in the viewpath.
In this example $(<) will expand to the name of the target, "targ1". The use of $(<) isn't necessary to support viewpathing but it is a good habit to develop. More advanced rules may be written to build different targets by reusing the same action. Such a rule cannot have the target hard-coded in the action block. The $(<) variable will always expand to the current target.
Note also that $(*) is used in the example instead of $(>). It is recommended to only use $(>) when you know you need it because this variable can cause confusion. For example if file abc was out-of-date but xyz was not, then $(>) would expand to abc as found in the viewpath but it would not include file xyz. That is usually not what is wanted.
We are always interested in 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.