On 2010-01-03 21:33-0500 Hazen Babcock wrote: > Alan W. Irwin wrote: >> >> Thus, I suspect that blank is the source of the problem here. Could you try >> again with an install prefix that doesn't have a blank in it? > > That seems to be the problem. If install to "C:\plplot" instead of > "C:\Program Files\plplot" then I can build the install tree examples > successfully (almost, see below).
> [out of order] This [separate build tree for installed examples] doesn't > quite work. The F77 file plf77demos.inc does not get copied. If > I copy this file by hand (to the f77 directory) then the F77 examples build > without problems. I didn't encounter this problem for revision 10735. Does it now work for you? > > It sounds like you are trying to fix the space in the path issue? I'm still > having the same problem v10734. Try the just-committed revision 10735. On Linux with embedded blanks in the top-level directory name for the source, build, and install tree, I finally got "make test_noninteractive" to work for both the build tree (with -DBUILD_TEST=ON) and the installed examples tree (with the new CMake-based build system for that case with a separate build tree) for the case where -DENABLE_ada=OFF -DENABLE_d=OFF -DENABLE_octave=OFF -DENABLE_ocaml=OFF -DENABLE_f95=OFF -DENABLE_java=OFF Could you please test this case yourself? (Your previous test was just a build test which is essential, but it is also nice to do full testing using the test_noninteractive and test_interactive targets where the compiled and script language examples are comprehensively executed.) To do this test on Windows you will need to install win-bash. In the course of investigating embedded blanks in the top-level directories of the source, build, and install trees, I discovered the following issues which have not yet been solved: * There was one strange workaround I had to do for a CMake add_custom_command bug (see my discussion on the CMake mailing list today) which works fine on Linux but may not work on Windows (which is why I am requesting the above test). * Our special CMake language support for Ada and D does not work properly if there is an embedded blank in the top-level directory of the source tree. I even did some special testing where I inserted a blank in the cmake PATH to attempt to replicate the problem for the normal CMake language support, but in fact there is no such problem so the embedded blank issue for Ada and D must be the result of something special that I am doing for that language support that is not being done in the normal CMake language support. However, currently I cannot figure it out. (This issue accounts for -DENABLE_ada=OFF -DENABLE_d=OFF above). * The perl script matwrap does not work properly for embedded blanks in directory variables. (-DENABLE_octave=OFF). * The camlidl programme does not work properly for embedded blanks in directory variables. (-DENABLE_ocaml=OFF). * There is a bug in Fortran 95 module dependencies for the case of embedded blanks. I have reported this bug on the CMake mailing list today. The build tree does not have this issue because the relative path to the location of the modules does not involve embedded blanks. But for the separate build-tree case for the installed examples (where I used a build tree so different from the installed examples tree that an embedded blank showed up in the (absolute or relative) path to the Fortran modules) this was an issue (which accounts for -DENABLE_f95=OFF above). * There is an embedded-blank bug in the installed java examples that does not appear for the build tree. I could not figure it out, but it accounts for -DENABLE_java=OFF, above. I will take responsibility for the above Ada and D issues (although it may be a while before I get to them again), and the add_custom_command and Fortran 95 issues require help from the CMake developers. Andrew, would you be willing to take responsibility for the matwrap embedded-blank issue and the installed java examples embedded-blank issue? Hez, could you take responsibility for (a) verifying the embedded blank issue with camlidl and (b) reporting that bug to the ocaml developers? I felt like I had opened a can of worms when I started investigating embedded blanks in the top-level directory names for the source, build, or install tree. However, many changes later I got everything to work (with the exceptions noted above). Thus, I think this has been a useful exercise since embedded blanks in directory names are a common scenario on Windows. I request our windows developers follow up on my work by running both the test_noninteractive and test_interactive targets for both the build tree (with -DBUILD_TEST=ON) and installed examples tree (for the new cmake-based build system for that case). 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 the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
