Re: [Plplot-devel] Debian packages

[Alan W. I. <ir...@be...>]

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
__________________________