[gentoo-dev] [PATCH 00/11] llvm-r2.eclass, to unmess pkg_setup and fix cross

["Michał Górny" <mgorny@gentoo.org>]

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