Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's Python support to 2.7. Now that both LLVM and LLDB both support Python 3, there's no longer a need to put an arbitrary limit on this. However, instead of removing the variable, D64443 expanded the list , which has the (presumably unintentional) side-effect of expression preference for Python 3. Instead, as Michal proposed in the original differential, we should just not set the list at all, and let CMake pick whatever Python interpreter you have in your path.
Details
- Reviewers
thakis cbiesinger mgorny - Commits
- rG23c8505c9c64: Merging r366447: --------------------------------------------------------------…
rG6d070f235084: Merging r366447: --------------------------------------------------------------…
rGcfcc2fea3c82: Merging r366447: --------------------------------------------------------------…
rG588351435cb3: Merging r366447: --------------------------------------------------------------…
rL369902: Merging r366447:
rL369901: Merging r366447:
rL369900: Merging r366447:
rL369899: Merging r366447:
rGa5359b1b0754: [CMake] Don't set Python_ADDITIONAL_VERSIONS
rC366447: [CMake] Don't set Python_ADDITIONAL_VERSIONS
rCRT366447: [CMake] Don't set Python_ADDITIONAL_VERSIONS
rLLD366447: [CMake] Don't set Python_ADDITIONAL_VERSIONS
rL366447: [CMake] Don't set Python_ADDITIONAL_VERSIONS
Diff Detail
- Repository
- rL LLVM
Event Timeline
Without this change, it is impossible to configure CMake with Python 2.7 on macOS, without either setting the paths manually, or completely removing any trace of Python 3 on the machine.
I'm in favor of this, but we should make sure there is documentation telling users how to explicitly choose the python version they want. I'm also curious, how does cmake determine which version to use if more than on interpreter is found?
Agreed, I'll update the docs.
I'm also curious, how does cmake determine which version to use if more than on interpreter is found?
If you don't specify a version (which we don't) it just picks the first one it finds (in your PATH).
Update the docs with information on the default behavior with regards to Python and how to overwrite it.
Makes sense. I suppose you want to update LLDBStandalone as well. And probably Python_ADDITIONAL_VERSIONS in clang & co are outdated.
llvm/docs/GettingStarted.rst | ||
---|---|---|
601–604 ↗ | (On Diff #210451) | FWIW, my experience yesterday was that I needed to also set PYTHON_LIBRARY and PYTHON_INCLUDE_DIR to avoid just erroring out with mismatches (but setting all three did work, once I figured out that PYTHON_LIBRARY needs to point to a file while the other two need to point to directories). It might be worth mentioning something along the lines of "You may also need to set PYTHON_LIBRARY and PYTHON_INCLUDE_DIR"? I phrased that as a question b/c I don't know if it's something that others will run into, or if I just have something funny in my environment somehow. |
llvm/docs/GettingStarted.rst | ||
---|---|---|
601–604 ↗ | (On Diff #210451) | This shouldn't be necessary anymore after this change! |
llvm/docs/GettingStarted.rst | ||
---|---|---|
601–604 ↗ | (On Diff #210451) | Actually, I think it will be necessary if you change PYTHON_EXECUTABLE while having the other two cached. However, I'd rather fix the code to do a second lookup than expect users to override everything. However, I still need to think how we could achieve that. Hmm, maybe instead of erroring out immediately we could clean cache vars and retry find_package()? |
Preferring Python 3, if present, was actually intentional on my behalf on the basis that we should use the newer Python if we can. But I did not realize this would break MacOS :( (and, it sounds like, any system where you have a python 3 binary but not devel package?)
I can confirm that -DPYTHON_EXECUTABLE=/usr/bin/python3 does work (I only tried with a deleted CMakeCache.txt). It is unfortunate that on most Linux systems we'd still default to Python 2
somehow when doing stage2 build, it is stubborn and does not respect any of PYTHON_EXECUTABLE. PYTHON_LIBRARY or PYTHON_INCLUDE_DIR that were passed with -D on cmake invocation even after they are added to -DDCLANG_BOOTSTRAP_PASSTHROUGH list. llvm finds its own python during stage2. in stage1 it respects the above settings.