JavaDeps-lu2.0.2 was released March 12. This update fixes a problem with JavaDeps hanging on Solaris machines when using Java 1.3 or 1.4. It should also fix similar hanging problems on other platforms, but we were only able to verify the problem on Solaris. For details and downloads see the JavaDeps page.
We are looking for projects interested in beta testing the next nmake release and/or our enhanced Java support (see Java Feature Plans below). We do hope for some specific Java support beta sites in addition to nmake beta sites. So if you would like to play with the latest Java support, but not the new nmake, that is fine.
Our goal is to make sure the latest changes do no break existing functionality or makefiles. The current plan is to run beta tests towards the end of April. If you are interested in being a beta site please contact us at email@example.com.
Local Package Builds
We are planning a new feature for Java support to allow local package builds. The current Java support only allows building at the root of the Java package. The local package feature will allow developers to launch builds from within a package. There are several motivations for this feature:
- Compatibility - It is a common practice to create a Makefile in every directory containing source when using nmake with C and C++, which controls the building of the source files in that directory. This feature allows Java developers to follow this common practice. However, there's some difference between the use of a Java local Makefile and that of a traditional C++/C local Makefile. A Java local Makefile will not be called recursively from higher level Makefiles to perform recursive builds, the local Makefile exists for the developer's convenience. Only the top level Java Makefile controls global builds.
- Convenience - A local Makefile allows developers to follow the familiar edit/build sequence without leaving the working directory.
- Performance - The local Makefile allows the developer to easily specify a set of directory-local Java files and through the minimum amount of work to bring the local targets up-to-date while updating non-package-local Java files if required.
If you are interested testing this feature let us know at firstname.lastname@example.org.
We are also investigating build support for tools involved in Java builds, other than the Java compiler itself. So far, we have identified the following tools that might need support:
Please let us know which tools you would like to see supported or if there are others we have missed.
We recently made some changes to the jar rules posted in the Creating Jar Files article in issue 5. The update allows multiple targets to share a common base name (but not suffix.) For example, the following is now supported but would not work with older rules:
mypkg.jar :JAR: classes mypkg.war :JAR: . JARTYPES=*.jar|*.html|*.xml
Notice both targets use the base "mypkg".
We plan to add jar file support to our official Java rules but we have no estimated time of availability. In the mean time if you are interested in the update you can download the new jar rules. Please see Creating Jar Files for details on using the rules.
Many projects include a date and time stamp in their build output showing
when each makefile starts and finishes building. This is usually done
.DONE special atoms in the
project's global makefile. For example:
.INIT: silent echo "+++ START $(VOFFSET)/$(MAKEFILE:B:S) - `/bin/date`" .DONE: silent echo "+++ DONE $(VOFFSET)/$(MAKEFILE:B:S) - `/bin/date`"
.INIT is made before any user targets.
.DONE is made after all other targets.
The above gives us output like this:
+++ START ./Makefile - Thu Mar 28 16:17:39 EST 2002 orb: +++ START orb/Makefile - Thu Mar 28 16:17:40 EST 2002 orb/abtu: +++ START orb/abtu/Makefile - Thu Mar 28 16:17:40 EST 2002 + /opt/exp/gnu/bin/gcc -O -I- -o clouds clouds.c +++ DONE orb/abtu/Makefile - Thu Mar 28 16:17:42 EST 2002 orb/c: +++ START orb/c/Makefile - Thu Mar 28 16:17:42 EST 2002 + /opt/exp/gnu/bin/gcc -O -I- -o plum plum.c +++ DONE orb/c/Makefile - Thu Mar 28 16:17:43 EST 2002 +++ DONE orb/Makefile - Thu Mar 28 16:17:43 EST 2002 +++ DONE ./Makefile - Thu Mar 28 16:17:43 EST 2002
In this example the
are sent to the shell for processing.
We can make a couple improvements on the original model.
- The time stamps can be generated using
.MAKEactions, which can be more efficient since nmake processes the action blocks directly instead of sending them to the shell.
- By using prerequisites of
.DONEinstead of these atoms directly, we allow users to use
.DONEin their makefiles without causing any conflicts with the time stamp rules.
.INIT : .GLOBALINIT .NULL .DONE : .GLOBALDONE .NULL .GLOBALINIT: .MAKE .VIRTUAL .FORCE print -- +++ START $(VOFFSET)/$(MAKEFILE:B:S) $("":T=R:F=%(%b-%d-%Y %H:%M:%S)T) .GLOBALDONE: .MAKE .VIRTUAL .FORCE print -- +++ DONE $(VOFFSET)/$(MAKEFILE:B:S) $("":T=R:F=%(%b-%d-%Y %H:%M:%S)T)
.GLOBALDONE targets replace
.DONE for global definitions. They
both have prerequisites of
.MAKE indicating nmake will
process the action blocks. This means we must be sure to use nmake style
syntax in the action blocks instead of shell style.
The last variable of the
:T=R edit operator gives
the relative time. The
:F formats the time and date.
The new output looks very similar to the original but you will notice the
date is formatted differently.
+++ START ./Makefile Mar-28-2002 16:18:35 orb: +++ START orb/Makefile Mar-28-2002 16:18:35 orb/abtu: +++ START orb/abtu/Makefile Mar-28-2002 16:18:35 + /opt/exp/gnu/bin/gcc -O -I- -o clouds clouds.c +++ DONE orb/abtu/Makefile Mar-28-2002 16:18:35 orb/c: +++ START orb/c/Makefile Mar-28-2002 16:18:36 + /opt/exp/gnu/bin/gcc -O -I- -o plum plum.c +++ DONE orb/c/Makefile Mar-28-2002 16:18:36 +++ DONE orb/Makefile Mar-28-2002 16:18:36 +++ DONE ./Makefile Mar-28-2002 16:18:36
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.