If you are an user in one of the Lucent spinoff groups, Avaya or the Microelectronics group, you may be wondering how the split will affect nmake support. We currently support many users outside of Lucent, AT&T being the largest but also many smaller customers. We will continue to support any users that split off of Lucent, and any external users for that matter, so you should not worry about continued support. The only change will be once the split is complete we will most likely not be able to access your machines to do trouble shooting. This can sometimes make problems more difficult to find but we can generally find ways to deal with it. You will also need to start accessing our external web site at http://www.bell-labs.com/projects/nmake/, rather than the internal Lucent site.
Release lu3.3 is now available for Tier 1 and Tier 2 platforms plus a few extra. This includes Solaris, SunOS, HP-UX, NCR, SGI, AIX, Unixware 2.1, and Linux® (i386). Check the download and availability pages for platform availability.
Release lu3.3 offers the following new features, see the release notes for the full list of changes.
- Improvements to Probe
- Export nmake Variables to Shell
- Lucent C++ Instrument Support
- Include Makefile Expansion
- More Control of :LIBRARY: for Shared Libraries
- EXTRASTATE Engine Variable
The nmake manuals have also been updated for release lu3.3 and are available for download. The manuals are in PDF format and are indexed and search-able, very handy for on-line reference when using Adobe Acrobat Reader. Of course the PDF files may also be printed to make hard copies.
In the previous issue we reported that Sun was investigating -I- support for their compilers but had not yet agreed to anything. Things have changed since then and we are happy to say Sun is working on -I- support for the compiler's 6.1 release. We have tested a 6.1 beta release which includes the -I- feature in the C++ compiler. It is great news that -I- appears to be well implemented. In addition we are hoping to get prefixinclude support for completion. You have all been influential in this decision but we would like to specially thank the AMP/PCS Network Application Development Organization in Indian Hill Court of the Wireless Network Group for their tireless effort in making SUN's implementation of -I- a reality!
In regards to the mailing list we announced last issue, there appears to be a problem subscribing to the list from inside AT&T. Folks from AT&T who send email to the subscription address, firstname.lastname@example.org, have been getting an email bounce and the request never reaches its destination. However, other external users are able to use this address with no problem. We have searched for a cause inside Lucent but it appears the problem is coming from AT&T. So far we have not been able to reach anyone in AT&T to look at it, so we would appreciate if any of our AT&T users could forward this issue to the proper folks and have them get in touch with us at email@example.com.
We have begun defining and documenting the nmake cpp features which are instrumental in supporting a viewpathing build environment. This includes the -I- and prefixinclude features. The documentation is being made available to aid compiler vendors in adding these features natively in order to reduce or eliminate the dependency on nmake's cpp.
The first draft is currently available and contains the following sections:
- The -I- and prefixinclude Features (Descriptions and Examples)
- Specification of search rules for C/C++ include directive
Work is under way to add a test suite to test a compiler for the availability and correctness of the -I- and prefixinclude features.
The nmake C Preprocessor documentation is available on the web at:
Feel free to browse around the documentation. If you are in contact with any vendors who may be interested please point them to the documentation as well. The more these features are supported the better for everyone.
Here is a quick note to let you know HP is officially dropping support for their cfront based C++ compiler. If you are still using this compiler it is time to start thinking about an upgrade plan.
You can find the official information on HP's web site - http://www.hp.com/esy/lang/cpp/cxx.html#notice Here is a small quote from their announcement:
The support period for HP C++ (cfront) will end on August 1, 2001. During this support period, customers who have support contracts for HP C++ will continue to receive support assistance from the HP Response Center. HP C++ (cfront) will be supported on HP-UX 10.01, 10.10, 10.20 and 11.0 during the support period.
IONA's patch 38 to Orbix 3.0.1 fixes a problem some people have encountered when running the IDL compiler on HP-UX under nmake. The problem does not seem to come up when running the IDL compiler from the command line, so it is a bit confusing. Patch 38 fixes the following error:
/usr/lib/dld.sl: Unresolved symbol: _SYSTEM_ID (data) from /usr/lib/libc.2 /usr/lib/dld.sl: Unresolved module for symbol: _memset (code) from /usr/lib/libc.2 ksh: 17086 Abort(coredump)
You can visit IONA's update support site at http://www.iona.com/support/update/.
In previous issues we talked about building java code and creating jar files. Now lets look at building java code which is generated from IDL files. This will cover both the .idl to .java conversion and compiling the generated .java file to .class files. This can be tricky because it is generally unknown at build time what .java files will be created by the IDL compiler. So in a sense we want to blindly compile all the generated java code without knowing the filenames, but we also want to provide some level of build-avoidance so all the files are not recompiled during incremental builds.
Here are some rules for building java code from IDL source. Download at least rules.mk, the others may be downloaded or just used as reference examples.
- rules.mk - Contains the rules to make java code from .idl files and to compile the resulting java code.
- idl.mk - Example makefile that generates java code from .idl files.
- java.mk - Example makefile that compiles the generated java code.
- Makefile - Example makefile that calls ild.mk and java.mk.
These rules are being used by a few projects now. There have been some changes due to feedback from one of the users (thanks!) so even if you are already using rules from us you might want to check out the latest version here.
Everything should be fairly generic. Slight adjustments to some variables and the .SOURCE.class settings may be necessary.
The :JIDL: operator is used to generate java code from the .idl files.
:JIDL: a.idl b.idl c.idl
The :JAVAPKG: operator is used to compile the java packages generated by :JIDL:.
<class_directory> :JAVAPKG: <source_root_directory> ie: $(VROOT)/class :JAVAPKG: com/lucent/stc
The <class_directory> is the root of the directory where the .class files are written by the javac compiler (by using the -d javac flag). The <source_root_directory> is the root of the directory containing the java source packages, where the IDL compiler output the source. nmake will recursively build each package (directory) underneath the specified source root. Or you can specify specific package directories to build only those packages or to force some build order. Basically :JAVAPKG: recursively finds all the .java files under the specified source root directory (RHS), and passes a directory worth of files to javac in one call to compile the whole package at once. This was written to handle the IDL generated files because it is unknown at build time exactly what files will be generated. But this could also be used to compile hand-written java code or a mixture of both.
We found a great time savings in compiling a whole package at once rather than compiling individual java files one at a time. But if any one .java file changes then the whole package is recompiled. This seems to be the safest thing to do until nmake can properly scan the java code and understand all the dependencies.
In some cases where a package contains a lot of java source code the compiler may fail with a java.lang.OutOfMemoryError error when compiling all the source at once. The MAX variable defined in :JAVAPKG: sets the maximum number of .java files to compile in one shot. In case a package contains more than MAX number of source files only MAX number of files are compiled at one time until the package is complete in order to get around the java.lang.OutOfMemoryError error. MAX is originally set to 200 and should be decreased if this error shows up.
Some projects have their .idl files generate java code under some package path, such as ./com/lucent/stc/, by using the "-jO ./" and "-jP com.lucent.stc" arguments to the idlj command. The first tells idlj to deposit the java code relative to the current directory, the second specifies a root package string. Additional package directories would be created under ./com/lucent/stc/ by idlj with several .java files for each package, and sometimes there are "sub-package" directories under the package directory with more .java files. These package paths are defined by the variables PKGPRFX and PKGPATHPRFX defined in rules.mk.
The :JAVAPKG: operator expects the source java files to be in a relative directory corresponding to where the .class files are written by the compiler. So if the compiler will output com/lucent/gui/x.class then the java file should be found as com/lucent/gui/x.java. But the roots of each do not have to be the same. That is you can use ./com/lucent/gui/x.java and compile to $(VROOT)/class/com/lucent/jaguar/gui/x.class. Likewise, if the class files are only created as gui/x.class then you only want gui/x.java for the source. Depending on how the class files are output you may need to use the -jP idlj argument as mentioned above.
The :JAVA: operator defined here has some RMI support in it which may not be needed for all projects, but it's presence shouldn't hurt anything. :JAVA: is called by :JAVAPKG: but it can also be used alone to compile existing java code.
Everything may sound complicated but it is pretty simple once you get it working. As usual, if there are any questions or problems with these rules just contact us at firstname.lastname@example.org.
Some other notes which may be of interest:
- The IDL compiler does not handle viewpathing for include files properly. This FAQ pages provides a work-around for the Orbix 2000 IDL compiler.
- Orbix patch 38
- Some folks have reported a problem using the idl compiler on HP-UX. The problem was solved by upgrading the idl compiler from IONA.
Here is a function, DIRECURSE, to recursively list the directories of the current node. Just in case any ever needs something like that.
DIRECURSE :FUNCTION: local lowerdirs rdirs lowerdirs = if "$(%:L)" lowerdirs := $(%:X=$(%:L):T=F:A!=.REGULAR) end if ! "$(lowerdirs)" return $(%) end for DIR $(lowerdirs) rdirs += $(DIR:D) $(DIRECURSE $(DIR)) end return $(rdirs:H=U)
Here is a quick example run.
$ cat Makefile test: silent print $(DIRECURSE dir1) silent print $(DIRECURSE dir1/dir12) $ ls -FR dir1 #-- what the directory structure looks like dir1: dir12/ foo dir1/dir12: dir121/ dir1/dir12/dir121: $ nmake dir1 dir1/dir12 dir1/dir12/dir121 dir1/dir12 dir1/dir12/dir121
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 email@example.com. All ideas, suggestions, and comments are welcome.