On Thu, Aug 11, 2011 at 12:40:58PM -0700, Alan Irwin wrote: > Hi Andrew: > > Orion, you should read this because there is a comment for you > at the end with regard to testing your Fedora installation.
Alan, Thanks for the testing! > > On 2011-08-11 13:06+0100 Andrew Ross wrote: > > > On Thu, Aug 11, 2011 at 10:38:39AM +0100, Andrew Ross wrote: > >> On Wed, Aug 10, 2011 at 12:57:03PM -0700, Alan Irwin wrote: > >>> > >> > >>> III. After that change > >>> > >>> debuild --no-lintian -us -uc -b -j4 2>&1 >| debuild.out > >>> > >>> failed to work. Although debuild (and dpkg-buildpackage which it is > >>> the front end for) support parallel builds with, e.g, the -j4 option, > >>> and so does PLplot, it looks like your Debian packaging does not > >>> support that option yet. I did notice for my last try below > >>> without the -j4 option that a lot of cpu time is being consumed with > >>> tests. Assuming your debian package build rules are running something > >>> like "make test_noninteractive" in the build tree, a parallel build > >>> option would serve to really speed that up for individuals who are > >>> trying to build the package themselves. > >> > >> Currently I'm running ctest to perform all the tests which doesn't > >> parallelise. I should probably change to make test_noninteractive. I assume > >> this will parallelise then. > > The advantage of test_noninteractive over ctest is that it has full > dependencies done correctly so you don't need to run "make all" before > it (which would build some stuff not actually needed for testing). > > OTOH, I think we should maintain ctest as well since it has dashboard > potential which could become quite useful for us if somebody was > willing to set up a cmake dashboard for PLplot. Modern ctest does not > allow any dependencies on targets, but it does allow dependencies > between tests (in fact we use that feature right now, see > set_tests_properties in plplot_test/CMakeLists.txt.) It also allows > parallel tests. I think that would be trivial to set up, but I will > leave that to others. > > > > > Bit more complicated than that. > > > > Of course debian/rules is a makefile so the -j option tries to parallelise > > which fails because it includes multiple calls to cmake which must be > > serialised. Including the .NOTPARALLEL target prevents parallelisation of > > the top level rules file. Instead the -j option is passed down to the > > plplot makefiles, where it works as expected. I've tested it and a parallel > > build now seems to function as expected. Thanks for pointing this out Alan. > > I started with a fresh checkout, and after that > > debuild --no-lintian -us -uc -b -j4 2>&1 >| debuild.out > > just works for me and produces the following 20 debs Good! > libcsiro0_5.9.8-1_amd64.deb > libplplot-ada_5.9.8-1_amd64.deb > libplplot-c++9c2_5.9.8-1_amd64.deb > libplplot-d_5.9.8-1_amd64.deb > libplplot-dev_5.9.8-1_amd64.deb > libplplot-fortran9_5.9.8-1_amd64.deb > libplplot-lua_5.9.8-1_amd64.deb > libplplot-ocaml_5.9.8-1_amd64.deb > libplplot9-java_5.9.8-1_amd64.deb > libplplot9_5.9.8-1_amd64.deb > octave-plplot_5.9.8-1_amd64.deb > plplot-doc_5.9.8-1_all.deb > plplot-tcl-dev_5.9.8-1_amd64.deb > plplot-tcl_5.9.8-1_amd64.deb > plplot9-driver-cairo_5.9.8-1_amd64.deb > plplot9-driver-gd_5.9.8-1_amd64.deb > plplot9-driver-qt_5.9.8-1_amd64.deb > plplot9-driver-wxwidgets_5.9.8-1_amd64.deb > plplot9-driver-xwin_5.9.8-1_amd64.deb > python-plplot_5.9.8-1_amd64.deb > > (Note for later reference that python-plplot is in the list.) I > installed those with > > dpkg --install *.deb > > with no obvious installation errors. But then I tested that > installation using the cmake-based build system for the installed > examples, and I found some issues. > > 1. The command > > cmake /usr/share/doc/libplplot9/examples >& cmake.out > > worked, but python is incorrectly disabled because of the line > > set(ENABLE_python OFF) > > in the file > /usr/share/doc/libplplot9/examples/cmake/modules/plplot_configure.cmake > > That file is the result of configuring the relevant bits of the build > environment for the installed examples tree. So somehow, that file > was produced when the Debian package build had python (temporarily?) > disabled. Does that make sense as an explanation? The only way the > CMake-based build and test system for the installed examples would > work correctly is for one coherent build. The problem is that python support is built for several different versions of python. This involves first building with no python support then rerunning cmake and rebuilding explicitly for each available python version. I'll have to think of a way around this. > 2. The subsequent "make test_noninteractive" fails because of > permission problems. Those issues are caused by the two chmod > commands in plplot_test/plplot-test.sh.cmake. I have no idea why we > felt it was important to change the permissions of the testing > scripts. That may be a leftover from the cvs and autotools days. But > with svn and cmake you have full control of the permissions of scripts > in the source tree, the build tree, and the install tree. Could you > analyze those to make sure they are done correctly, remove the > offending chmod lines from plplot_test/plplot-test.sh.cmake, and test > the result using the cmake-based build system for the installed > examples? The permissions are already correctly set by cmake so we can just delete the chmod commands. I've now done so. I also made sure test_d.sh is executable in the build tree for testing. All other scripts already were. > I temporarily worked around the permissions issue by > > cp -a /usr/share/doc/libplplot9/examples /tmp > > cmake /tmp/examples >& cmake.out > make -j4 test_noninteractive >& test_noninteractive.out > > and > > make -j4 test_interactive >& test_interactive.out > > All was well with those (pythonless) tests so your debs are looking > promising. > > @Orion: > > Once the general PLplot permissions problem is straightened out by > Andrew, I suggest you also try running the CMake-based build and test > system for the installed examples on Fedora from an ordinary user > account to insure that installation is correct. There were a couple of other lintian issues which I should now also have fixed. One was that plplot_octave.oct was being installed with the executable bit set. I can't see any reason for doing this unless it is required on other platforms. If no-one has a reason for keeping it I'll change bindings/octave/CMakeLists.txt to change this. The one outstanding issue is the python examples being disabled. I'm working on that, but I'm off on holiday after today so it probably won't get done until my return. Andrew ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
