if( ${PYTHON_VERSION_STRING} VERSION_LESS 2.7 )
message(FATAL_ERROR “Python 2.7 or newer is required”)
endif()
But lit seems to still be stuck in a Python 2.5 world. For example, detectCPUs is redundant now that we have multiprocessing.cpu_count() (multiprocessing requires >=2.6). And there are a bunch of other Python 2.5 workarounds floating around inside lit. I’m actually not sure if there are 2.6 workarounds.
Anyway, does anybody know if somehow, despite the CMake check, lit is still being run with Python <2.7 on any bots or anywhere? If not, I’d like to make a couple cleanup patches.
Great! I’ll circle around to this at some point. Despite the “obvious” nature of it I still am wary of underestimating the cruftiness of the buildbots, so I’ll probably do it some time at night when the bots are mostly green so that I can easily see if any bots are broken by this.
It’s possible to implement such that it executes as expected in python3 or python 2. Is anyone already working on that? If not, I’d be willing to see what it takes.
If successful, it would probably be appropriate to put just “env python” in the shebang.
Note that straddling 2 and 3 is significant ly easier if you can safely assume 2.7.
Still haven’t gotten around to this, but just now I’ve randomly run into set(Python_ADDITIONAL_VERSIONS 2.7 2.6 2.5) in compiler-rt/CMakeLists.txt
I assume that can be nuked too?
It is possible to create a script that is both valid shell and Python that
will e.g. invoke `which` to find the appropriate python binary and execute
it. See mozilla-central: mach@5e0140b6d11821e0c2a2de25bc5431783f03380a for
an example. With a little tweaking, you could have it search for multiple
pythonX.Y binaries and pick the most appropriate one.