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

[Chris Bieneman via llvm-dev]

> On Jan 29, 2020, at 5:23 AM, Brian Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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!)

llvm-build exists for two reasons, one legacy, one still an issue. Back when we supported both autoconf and CMake llvm-build provided a way to express the build dependency graph in one place and have both build systems respect it. Additionally it generates the tables that drive llvm-config. Deprecating llvm-config in favor of pkg-config and CMake packages has been discussed, but there has been no decision.

Removing llvm-build is technically feasible even if we continue supporting llvm-config, but a non-insignificant amount of work to get CMake to generate the headers needed in the llvm-config build.

-Chris

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev