[LLVMbugs] [Bug 19527] New: the test for PYTHON_EXECUTABLE doesn't take custom python installations and environment variables into account

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19527

            Bug ID: 19527
           Summary: the test for PYTHON_EXECUTABLE doesn't take custom
                    python installations and environment variables into
                    account
           Product: Build scripts
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: cmake
          Assignee: unassignedbugs at nondot.org
          Reporter: emanuelecestari at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

If you consider the file CMakeLists.txt that it's in the llvm root, at the line
349 you have some code that uses the PYTHON_EXECUTABLE

[ code ]
...
  COMMAND ${PYTHON_EXECUTABLE} ${LLVMBUILDTOOL}
            --native-target "${LLVM_NATIVE_ARCH}"
            --enable-targets "${LLVM_TARGETS_TO_BUILD}"
            --enable-optional-components "${LLVMOPTIONALCOMPONENTS}"

...

[ /code ]

This test fails under a customized python installation, furthermore the
deduction of the right value for PYTHON_EXECUTABLE is subject to the
FindPythonInterp builtin cmake module which is basically not documented and if
you use cmake you have no clue and no guarantees about what steps and processes
are activated by cmake the "right" Python installation. For example there are
expansion rules that have effect on the value that the user is giving to the
related cmake cache entry ? The Python interpreter it's just a valid file with
a valid "pythonish" name ? Cmake is testing this hypothetically valid python
executable with some module-specific tests or it takes for granted that
something that looks like a binary will work ? And bla bla, plus other
dissertations about the fact that this module gives no insights and
informations.
You are probably thinking that you can inspect the source code for the right
cmake module to know what cmake is really doing but this way of thinking
doesn't really take into account the fact that something really critical as the
location of the right python executable ( since llvm/clang is using python a
lot and relying heavily on it ) it's not an invariance, it's not even something
with a consistent behaviour .

As I mentioned there is also an extra problem with this approach, python, and
this is even more popular for many custom python installations, often relies on
some special environemnt variables like PYTHONHOME and PYTHONPATH (
https://docs.python.org/2/using/cmdline.html for more ), you can't just use the
full path to the python executable and feed some scripts and flags to it, it's
not going to work out that well.

Also many GNU/Linux distributions provide a default python installation, so if
you have 1 system-wide python installation plus another custom one that you are
going to use as a developer library, you end up with having at least 2 python
installations at the same time, and this leads us to the problem that exporting
PYTHONHOME or PYTHONPATH it's likely to cause more harm than good.
There should be a way to pass and use customized PYTHONPATH,PYTHONHOME right
inside the scripts that are using the PYTHON_EXECUTABLE otherwise this is not
going to work at all and the result of the script will be 100% unreliable .
-----
this is about the r206684 from the svn trunk, I also posted my configuration
and softwares used in a dedicated discussion on llvm-dev here
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/072312.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140423/a6afe94f/attachment.html>