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
signature.asc
Description: This is a digitally signed message part
