On 2008-02-06 12:25-0800 Alan W. Irwin wrote: > [...Y]ou were right that the class files have to be built in a > particular order since, e.g., plplotjavac.java has references to > PLGraphicsIn. I have now done a lot of grepping to determine such > dependencies and put in some CMake logic to implement such class > dependencies. Please check my work (revision 8218) to make sure my grepping > (and limited knowledge of Java) found the correct list of class > dependencies. Early indications for this dependency work are good because > the fix seems to sort out the parallel build issues for the java bindings on > my hardware platform which is another big step forward. > > Note, there are still parallel build issues remaining if the java examples are > built, but now that there is no interference from java bindings dependency > issues, I am confident it will be straightforward to fix.
A redundant and poorly implemented test was being done for the java examples for whether the plplot_core target had been built. Removal of that test appeared to solve the last of the parallel build issues. I followed up with extensive testing of a number of configurations including a full build of PLplot software and documentation with "make -j N" for a variety of N values. All seemed well until a very specific combination (no documentation build, full software build, N=4) turned up another kind of class file dependency that I had missed due to my lack of Java knowledge. revision 8220 puts in the necessary extra class file dependencies, and all seems well again. However, it appears test results critically depend on the hardware, value of N, and type of configuration so the fact that everything seems clean for me now is just an encouraging indication I have addressed all the parallel build issues, but this good result is not definitive. Thus, I strongly encourage everybody to routinely use the parallel build option not only as a matter of convenience (quicker builds on multi-processore boxes) but also to make sure we don't introduce any new dependency issues or have any issues that are currently hidden for my present hardware (two processors), software platform, and PLplot configuration. To summarize the current release status, we can now strike the parallel build issue from the list (subject to parallel-build testing results from others). That leaves the psttf/libLASI segfaults, the python single-precision issue, and the recently introduced wxwidgets issue. I plan to spend my remaining PLplot time before the release this weekend helping Andrew with the psttf/libLASi segfault issue. There are no guarantees we will get done before the release, but we can live with that. I am going to let the python single-precision issue slide until after the release since I feel the psttf issue should have higher priority. Based on past experience, I am sure Werner will quickly sort out the wxwidgets issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
