Hi Andrew: It is great to see your Debian packaging rounding into shape. More below....
On 2011-08-12 10:43+0100 Andrew Ross wrote: > On Thu, Aug 11, 2011 at 12:40:58PM -0700, Alan Irwin wrote: [...] >> 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. Well, it is a bit ugly, but if push comes to shove, you could configure a FORCE_INSTALL_ENABLE_PYTHON option and replace set(ENABLE_python @ENABLE_python@) with if(FORCE_INSTALL_ENABLE_PYTHON) set(ENABLE_python ON) else(FORCE_INSTALL_ENABLE_PYTHON) set(ENABLE_python @ENABLE_python@) endif(FORCE_INSTALL_ENABLE_PYTHON) in examples/plplot_configure.cmake_installed_examples.in. By default FORCE_INSTALL_ENABLE_PYTHON would be OFF, but you could set it to ON for your special case of building everything but python. Of course, that could have some installed examples tree build system issues if it turns out that any of your special python builds failed, but I think normally this would work. Ideally, this would all be done as a Debian patch since it is a bit ugly and certainly confusing to our normal users. Alternatively, you could run a sed script to change the configured and installed version of this file in the install tree after the fact to change set(ENABLE_python OFF) to set(ENABLE_python ON). > >> 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. Thanks. > 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. I have looked carefully at this question, and in the build tree the shared object (as opposed to libraries) execute bit is set while in most cases it is not set in the build tree. When I have spot checked a few cases, nothing special was being done to enforce these install tree permissions so it appears CMake policy is normally in exact agreement with Debian policy in this regard. Here are the exceptions in the install tree (note I weed out the symlinks to libraries). software@raven> find -name "*.so" -o -name "*.oct" |xargs ls -l |grep -v ">" |grep rwx -rwxr-xr-x 1 software software 6240 Jul 1 16:46 ./lib/ocaml/3.11.2/stublibs/dllplcairo_stubs.so -rwxr-xr-x 1 software software 135889 Jul 1 16:46 ./lib/ocaml/3.11.2/stublibs/dllplplot_stubs.so -rwxr-xr-x 1 software software 2627070 Jul 1 16:46 ./share/plplot_octave/plplot_octave.oct In all of these cases we do something special with the permissions. To be consistent with this CMake/Debian policy it appears to me that all of dllplcairo_stubs.so, dllplplot_stubs.so, and plplot_octave.oct should have their executable bit turned off as well in the install tree. For the first two, (in bindings/ocaml/CMakeLists.txt and bindings/ocaml/plcairo/CMakeLists.txt we use install(PROGRAMS ... I think that if that is changed to install(TARGETS ... just like we use for other shared objects, we will get the right install permissions by default, but you should check that the ocaml examples still work properly in the install tree for that case. plplot_octave.oct is a special case where we force certain permissions (presumably because of its unknown [to CMake] "oct" suffix). I think you should go ahead and change those special permissions to not set the execute bit, but, of course, the installed result should be tested as well. BTW, do you know why Debian (and also apparently CMake) have a policy of not having the execute bit set for shared objects in the install tree? Just curious... 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 __________________________ ------------------------------------------------------------------------------ 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
