[llvm-dev] [RFC] Python 2 / Python 3 status

[Brian Gesiak via llvm-dev]

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
> scripts.

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