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