python3: llvm-3.1 fails to build with python3 selected

[jonesc@…]

Title says it all ... llvm-3.1 fails to build for me on OSX 10.7 with Xcode 4.2

log file attached.

Chris

[macsforever2000@…]

In the future, please Cc the maintainer(s).

[jeremyhu@…]

:info:build make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.1/llvm-3.1/work/trunk'
:info:build llvm[0]: Constructing LLVMBuild project information.
:info:build Traceback (most recent call last):
:info:build   File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.1/llvm-3.1/work/trunk/utils/llvm-build/llvm-build", line 3, in <module>
:info:build     import llvmbuild
:info:build   File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.1/llvm-3.1/work/trunk/utils/llvm-build/llvmbuild/__init__.py", line 1, in <module>
:info:build     from main import main
:info:build ImportError: No module named main

It builds fine for me here. This looks like python related madness, so /shrug ... =/

[jonesc@…]

Sorry about the cc - I thought the bug system would automatically cc the maintainers of the port ... Seems odd I have to do it by hand...

Anyway, could it matter which python version I am using. I have macports python32 install and have 'port selected' it .... ?

Chris

[jonesc@…]

The problem does seem to be related to my use of python32 as my default python version. If I switch back toy either macports python27, or the system python version, the build goes OK.

If llvm-3.1 depends on python during the build phase, wouldn't it be best to explicitly depend on a macports python version (2.7, as that seems to work) and use that, rather than just pickup whatever the user has as their 'python' version via $PATH ?

cheers Chris

[jeremyhu@…]

Ok, then it seems the llvm ports (and probably clang, can you please test clang-3.1) need some python magic... yick.

[jonesc@…]

clang-3.1 does indeed suffer from the same problem. log attached, in case its useful ...

Chris

[jeremyhu@…]

llvm Portfile patch

[jeremyhu@…]

Does this patch to the llvm-3.1 Portfile address the problem for you?

[jonesc@…]

Sorry for the delay in getting back.

I'm afraid it don't work. Same error as before. See attached log.

Note, you can (I hope) reproduce this yourself by just installing python32 and setting it as your default, using

sudo port select python python32

Chris

[jonesc@…]

Any progress on fixing this ?

[jeremyhu@…]

I don't use python3, and there's an easy workaround, so it's not a priority for me. Patches are welcome.

Try setting the PYTHON_EXECUTABLE environment variable:

$ grep -R PYTHON .
./CMakeLists.txt:if( NOT PYTHONINTERP_FOUND )
./CMakeLists.txt:Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
./CMakeLists.txt:  COMMAND ${PYTHON_EXECUTABLE} ${LLVMBUILDTOOL}
./test/CMakeLists.txt:set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
./test/CMakeLists.txt:  COMMAND ${PYTHON_EXECUTABLE}
./test/lit.cfg:# Propagate PYTHON_EXECUTABLE into the environment
./test/lit.cfg:config.environment['PYTHON_EXECUTABLE'] = getattr(config, 'python_executable',
./test/lit.site.cfg.in:config.python_executable = "@PYTHON_EXECUTABLE@"
./test/Makefile:	@$(ECHOPATH) s=@PYTHON_EXECUTABLE@=python=g >> lit.tmp
./test/Scripts/coff-dump.py.bat:%PYTHON_EXECUTABLE% -u %LLVM_SRC_ROOT%\test\Scripts\coff-dump.py %1 %2 %3 %4 %5 %6 %7 %8 %9
./test/Scripts/elf-dump.bat:%PYTHON_EXECUTABLE% -u %LLVM_SRC_ROOT%\test\Scripts\elf-dump %1 %2 %3 %4 %5 %6 %7 %8 %9
./test/Scripts/macho-dumpx.bat:%PYTHON_EXECUTABLE% -u %LLVM_SRC_ROOT%\test\Scripts\macho-dump %1 %2 %3 %4 %5 %6 %7 %8 %9
./tools/clang/bindings/python/README.txt:$ env PYTHONPATH=$(echo ~/llvm/tools/clang/bindings/python/) \
./tools/clang/test/CMakeLists.txt:if(PYTHONINTERP_FOUND)
./tools/clang/test/CMakeLists.txt:    COMMAND ${PYTHON_EXECUTABLE}
./tools/clang/test/CMakeLists.txt:      COMMAND ${PYTHON_EXECUTABLE}
./tools/clang/test/Makefile:	@ $(PYTHON) $(LLVM_SRC_ROOT)/utils/lit/lit.py \
./utils/lit/lit/TestingConfig.py:                        'PYTHONUNBUFFERED' : '1',

[jonesc@…]

Totally fair point ;)

If and when I have time, I'll see if the PYTHON_EXECUTABLE workaround works or not.

cheers Chris

[jmr@…]

It doesn't look like modifying anything in the environment will work. It executes llvm-build directly, not as an argument to an interpreter, so the #!/usr/bin/env python in the script gets used. Just patching that to /usr/bin/python should be fine.

Upstream should probably add an AM_PATH_PYTHON to configure, and a $(PYTHON) to the invocation in Makefile.rules.

[russel@…]

Cc Me!

[russel@…]

Just a note that I was also seeing this problem, or a directly related problem, and tweeted about it. @neverpanic replied pointing me here. With my usual python32 as default I cannot install LLVM-3.1, switch to python27 and it works fine.

[samkass-macports@…]

If you have python installed through MacPorts, you can do this to make it work:

sudo port select python python27

[jonesc@…]

Replying to samkass-macports@…:

If you have python installed through MacPorts, you can do this to make it work:

sudo port select python python27

Well yes.... But that is not the point really. llvm should really be insensitive at build time to the version of python a user has opted to use.