[llvm-dev] [RFC] Python 2 / Python 3 status
Brian Gesiak via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 29 05:23:36 PST 2020
On Wed, Jan 29, 2020 at 5:26 AM Serge Guelton via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> My personal take on this would be to start moving forward. Still supporting both
> version this year, but obsoleting Python 2.7 and requiring, say Python 3.6,
> starting January 2021 looks like a good compromise.
I'm relatively new to LLVM so my +1 doesn't count for much, but I am
very supportive of this idea! I maintain a downstream fork of LLVM at
Facebook, and Python 2 will no longer be made available in our
developer environment at some point in 2020. So if LLVM is still
maintaining Python 2-compatible programs in 2021, I'll need to install
a Python 2 interpreter on a personal computer of mine to test any
changes I make, which would be a big inconvenience.
> Even if Python is not a core build requirement, it's used during some
> configurations steps (e.g. in the cmake export_executable_symbols function),
> for testing, and it is definitevely part of the user experience - several clang
> tools depend on it, as well as many lldb features. So it's not only about utility
My understanding is that the build relies upon 232 LLVMBuild.txt
files, which are processed by a Python program llvm-build. I think
that if one uses CMake to build, then Python is in fact a core build
requirement (I'm not sure if gn uses llvm-build?).
I don't want to derail the discussion here, but I have been meaning to
ask: I recall that it was once used more widely, but these days, why
does llvm-build exist? (Again, I'm a beginner in the project, so
forgive my ignorance here!)
I read through some of the code and from what I understand, one of its
main functions is to define the library dependencies of LLVM libraries
like LLVMX86CodeGen or LLVMObject, both as global properties in CMake
(build/LLVMBuild.cmake), and as a C struct that can be used by
llvm-config.cpp (build/tools/llvm-config/LibraryDependencies.inc). But
is there a reason these dependencies couldn't/shouldn't be hardcoded,
instead of being generated by the llvm-build Python executable?
I'm wondering if there's some dynamic build configuration feature of
llvm-build that I'm missing. What makes it hard to remove?
> Any thoughts?
Pardon my tangential questions about llvm-build -- thank you for
proposing this timeline!
- Brian Gesiak
More information about the llvm-dev