Hello,

Here's the newest eclass I've been working on. While llvm-r1 addressed
the problems of generating dependencies and matching LLVM package
versions, it retained a hacky awful pkg_setup(). This one aims to fix
that.

Note that the patchset contains a quick hack enabling testing the new
eclass on packages using llvm-r1 -- it's obviously not intended to be
merged.

PR for those who prefer quality Microsoft software: https://github.com/gentoo/gentoo/pull/39696

Now, on to some details.


The eclass aims to support two main uses of LLVM: as libraries to link
to, and as a tools to call at build time. The default setup tries to
handle both, and it will probably succeed for the general case, though
to get cross right, it may require some manual manipulation.

In the greatest simplification:

1. If you only link to LLVM and don't need to call anything, you need
to add a DEPEND and call llvm_chost_setup.

2. If you only call LLVM tools and don't link to it, you need to add
a BDEPEND and call llvm_cbuild_setup.

3. If you need both, then you add both DEPEND and BDEPEND, and call both
(i.e. llvm-r2_pkg_setup).

llvm_cbuild_setup is pretty similar to what the previous eclasses did.
It sets PATH, but unlike the old eclasses, it uses the correct BROOT
path.

llvm_chost_setup combines a few methods to make it most likely for
the build systems to find the correct LLVM installation. We set a bunch
of variables that are used by CMake's `find_package()` function, and we generate a custom llvm-config that uses the ESYSROOT install of LLVM
(except for --bindir, that refers to BROOT tools, if available).

Of course, individual packages may need different scenarios.
For example, sequoia-sq uses llvm-config to find libclang.so that's
loaded at build-time -- it won't work correctly with llvm_chost_setup
(though this will only affect cross-compilation), and needs plain llvm_cbuild_setup instead. Other packages may prefer no special setup
at all and instead will want some custom configure option pointing
at the LLVM installation.

Overall, I think it's the best "one size fits all" tool I could come up
with, and one that can be customized to fit other use cases. Please
test and lemme know what you make of it.


Michał Górny (11):
llvm-r1.eclass: Fix list in eclassdoc
llvm-r2.eclass: Copy from llvm-r1.eclass
HACK! llvm-r1 -> llvm-r2 (to ease testing)
llvm-utils.eclass: Support -b/-d to llvm_prepend_path
llvm-r2.eclass: Readjust for BROOT, split to llvm_cbuild_setup
llvm-r2.eclass: Add llvm_chost_setup, set CMake path variables
llvm-r2.eclass: Generate a llvm-config script for CHOST
llvm-r2.eclass: Update top-level docs for CBUILD/CHOST support
llvm-r2.eclass: Remove obsolete Meson LLVM_CONFIG hack
eclass/tests: Copy llvm-r1 tests to llvm-r2.sh
eclass/tests/llvm-r2.sh: Add tests for llvm-config

eclass/llvm-r1.eclass | 203 +----------------
eclass/llvm-r2.eclass | 474 +++++++++++++++++++++++++++++++++++++++
eclass/llvm-utils.eclass | 27 ++-
eclass/tests/llvm-r2.sh | 188 ++++++++++++++++
4 files changed, 690 insertions(+), 202 deletions(-)
create mode 100644 eclass/llvm-r2.eclass
create mode 100755 eclass/tests/llvm-r2.sh

--
2.47.1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

---
eclass/llvm-r1.eclass | 201 +-----------------------------------------
1 file changed, 2 insertions(+), 199 deletions(-)

diff --git a/eclass/llvm-r1.eclass b/eclass/llvm-r1.eclass
index e59bd9c317b9..79fe63df3f96 100644
--- a/eclass/llvm-r1.eclass
+++ b/eclass/llvm-r1.eclass
@@ -47,207 +47,10 @@ esac
if [[ -z ${_LLVM_R1_ECLASS} ]]; then
_LLVM_R1_ECLASS=1

-inherit llvm-utils
+inherit llvm-r2

-# == internal control knobs ==
-
-# @ECLASS_VARIABLE: _LLVM_OLDEST_SLOT
-# @INTERNAL
-# @DESCRIPTION:
-# Oldest supported LLVM slot. This is used to automatically filter out
-# unsupported LLVM_COMPAT values.
-_LLVM_OLDEST_SLOT=15
-
-# @ECLASS_VARIABLE: _LLVM_NEWEST_STABLE
-# @INTERNAL
-# @DESCRIPTION:
-# The newest stable LLVM version. Versions newer than that won't
-# be automatically enabled via USE defaults.
-_LLVM_NEWEST_STABLE=19
-
-# == control variables ==
-
-# @ECLASS_VARIABLE: LLVM_COMPAT
-# @PRE_INHERIT
-# @REQUIRED
-# @DESCRIPTION:
-# A list of LLVM slots suppo

On Sat, 2024-12-21 at 16:48 +0100, Michał Górny wrote:

Hello,

Here's the newest eclass I've been working on. While llvm-r1 addressed
the problems of generating dependencies and matching LLVM package
versions, it retained a hacky awful pkg_setup(). This one aims to fix
that.

Note that the patchset contains a quick hack enabling testing the new
eclass on packages using llvm-r1 -- it's obviously not intended to be
merged.

PR for those who prefer quality Microsoft software: https://github.com/gentoo/gentoo/pull/39696

Now, on to some details.

The eclass aims to support two main uses of LLVM: as libraries to link
to, and as a tools to call at build time. The default setup tries to
handle both, and it will probably succeed for the general case, though
to get cross right, it may require some manual manipulation.

In the greatest simplification:

1. If you only link to LLVM and don't need to call anything, you need
to add a DEPEND and call llvm_chost_setup.

2. If you only call LLVM tools and don't link to it, you need to add
a BDEPEND and call llvm_cbuild_setup.

3. If you need both, then you add both DEPEND and BDEPEND, and call both
(i.e. llvm-r2_pkg_setup).

llvm_cbuild_setup is pretty similar to what the previous eclasses did.
It sets PATH, but unlike the old eclasses, it uses the correct BROOT
path.

llvm_chost_setup combines a few methods to make it most likely for
the build systems to find the correct LLVM installation. We set a bunch
of variables that are used by CMake's `find_package()` function, and we generate a custom llvm-config that uses the ESYSROOT install of LLVM
(except for --bindir, that refers to BROOT tools, if available).

Of course, individual packages may need different scenarios.
For example, sequoia-sq uses llvm-config to find libclang.so that's
loaded at build-time -- it won't work correctly with llvm_chost_setup
(though this will only affect cross-compilation), and needs plain llvm_cbuild_setup instead. Other packages may prefer no special setup
at all and instead will want some custom configure option pointing
at the LLVM installation.

Overall, I think it's the best "one size fits all" tool I could come up
with, and one that can be customized to fit other use cases. Please
test and lemme know what you make of it.

Michał Górny (11):
llvm-r1.eclass: Fix list in eclassdoc
llvm-r2.eclass: Copy from llvm-r1.eclass
HACK! llvm-r1 -> llvm-r2 (to ease testing)
llvm-utils.eclass: Support -b/-d to llvm_prepend_path
llvm-r2.eclass: Readjust for BROOT, split to llvm_cbuild_setup
llvm-r2.eclass: Add llvm_chost_setup, set CMake path variables
llvm-r2.eclass: Generate a llvm-config script for CHOST
llvm-r2.eclass: Update top-level docs for CBUILD/CHOST support
llvm-r2.eclass: Remove obsolete Meson LLVM_CONFIG hack
eclass/tests: Copy llvm-r1 tests to llvm-r2.sh
eclass/tests/llvm-r2.sh: Add tests for llvm-config

eclass/llvm-r1.eclass | 203 +----------------
eclass/llvm-r2.eclass | 474 +++++++++++++++++++++++++++++++++++++++
eclass/llvm-utils.eclass | 27 ++-
eclass/tests/llvm-r2.sh | 188 ++++++++++++++++
4 files changed, 690 insertions(+), 202 deletions(-)
create mode 100644 eclass/llvm-r2.eclass
create mode 100755 eclass/tests/llvm-r2.sh

Merged now.

--
Best regards,
Michał Górny


-----BEGIN PGP SIGNATURE-----

iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmdyhXUSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOVsMH/ilb8xXagYAi3w1BwBrkHzszsA/OQy4b moxSgNMc9wBO0tCyc0nN3cqq815yvk1NwUva+dN+Kosq5WwPD6bwVyrB3EcV6C4I Dj/TMflLqzfVzSoKSW7lub60wg6ds7CedIlivEr7OksEMMe5CiJkL6bcNLi1O058 fHvKl7jaaoXeR9K6i2iRrVeQffZ1OePwyy6xg5jIwzSmK6Y22Pntsltj1cbCbgfu j23RicxHV1OsTaWXoSOf7MnZKm0RVfMGidT2vLVBPAlqvAswh8PZThgwqgI5GYtN E3aFBF9a2QAm1Z1tKeRWTFS7UwQCjh22ju5Gs29YWwmtaDTz1L9NFbU=
=wWC5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)