On Fri, Aug 12, 2011 at 04:46:24AM -0700, Alan Irwin wrote:
> 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).
I guess. I was thinking of trying to build with the default python,
then rebuilding with any other python versions required. Your
solution is a bit ugly, but might be easier.
>>> 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@...> 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.
I'll go ahead and do this then. I've had some other octave issues with
lintian so I may need to go back to using mkoctfile, although this doesn't
play nicely with swig. I've run out of time for the moment to look at this
and at the python issue, so I'll get back to it when I return from holiday.
> 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...
I think it is simply that shared objects are not executable on their
own so there is no point in having the executable bit set. Trying to
run the shared object would just produce a segmentation fault.
Andrew
|