Bug #2416

Python bindings are not build if both python3 and python2.7 are installed and python3 is set to be the default

Added by N. Köster over 7 years ago. Updated over 7 years ago.

Status:ResolvedStart date:10/30/2015
Priority:NormalDue date:
Assignee:J. Wienke% Done:

100%

Category:Build System
Target version:Robotics Service Bus - rsb-0.13

Description

Issue

Currently the CMakeLists.txt for RST only does an optional check whether to build bindings for Cpp, Java or Pyhton. If Python 3 is the default on a system and Python 2.7 is also installed, the Python bindings are not build. This does not throw an error but a only a single line saying bindings are not being build.

I would propose to have a negative check here - meaning that by default all bindings are build and if one fails, the installation is aborted. A user would then have to actively deselect bindings.

Example:

  • When deploying a distribution using the CITK Toolkit, one will have the following projects (when using RSB/RST) in a
  • If you have a system with both pyhton2.7 and python3 (default) installed, you may have
  • Which leads to
  • So the python bindings are silently excluded, which will finally lead to an error when building rst-converters-python (which really is not helpful as the rst-proto job finishes successfully). See
  • Can be fixed by replacing the symlink at /usr/bin/python to point to /usr/bin/python2.7 (which should not be necessary/is not always possible)

rst.proto.py2_version_fix.patch Magnifier (727 Bytes) N. Köster, 11/06/2015 04:04 PM

Associated revisions

Revision 39c53b8e
Added by N. Köster over 7 years ago

Fix python version check to automatically find 2.7

fixes #2416

Signed-off-by: Johannes Wienke <>

History

#1 Updated by J. Wienke over 7 years ago

The actual problem is that there is (or was) no dedicated macro to search specifically for python 2, which should still be available on every system.

Not building parts of a software in case dependencies are missing is actually a quite common pattern. So I wouldn't want to change that. If you find a solution to tell CMake to explicitly search for python 2, we could apply this.

#2 Updated by N. Köster over 7 years ago

N. Köster wrote:

  • Can be fixed by replacing the symlink at /usr/bin/python to point to /usr/bin/python2.7 (which should not be necessary/is not always possible)

As I learned: do not do this. Ever. Its really discouraged and can lead to the weirdest errors.

J. Wienke wrote:

The actual problem is that there is (or was) no dedicated macro to search specifically for python 2, which should still be available on every system.

This should do the job:

FIND_PACKAGE(PythonInterp 2.7 EXACT)

instead of

FIND_PACKAGE(PythonInterp)

in this file

J. Wienke wrote:

Not building parts of a software in case dependencies are missing is actually a quite common pattern. So I wouldn't want to change that.

I understand - that was just an idea form the usual build flow perspective on RS* components...

#3 Updated by J. Wienke over 7 years ago

N. Köster wrote:

This should do the job:

[...]

instead of

[...]

Since which CMake version is this supported?

#4 Updated by N. Köster over 7 years ago

J. Wienke wrote:

N. Köster wrote:

This should do the job:

[...]

instead of

[...]

Since which CMake version is this supported?

We will never know - it is not documented afaik. Attached fix.

#5 Updated by N. Köster over 7 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF