[v2] llvm: fix llvm-config to work again with multilib

Submitted by yann.dirson@blade-group.com on Oct. 8, 2020, 10:38 a.m. | Patch ID: 177053

Details

Message ID 20201008103852.803147-1-yann@blade-group.com
State New
Headers show

Commit Message

yann.dirson@blade-group.com Oct. 8, 2020, 10:38 a.m.
From: Yann Dirson <yann@blade-group.com>

Newer llvm versions have changed the logic for finding libraries,
which prevents Mesa from building with PACKAGECONFIG[gallium-llvm]:

The problem is visible in mesa/do_configure with this in local.conf:

    PACKAGECONFIG_append_pn-mesa += " gallium-llvm"
    require conf/multilib.conf
    MULTILIBS = "multilib:lib32"
    DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937

This patch comes from meta-amd#dunfell for llvm-9.0.1, adapted for llvm-10.0.1.

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
 ...-llvm-allow-env-override-of-exe-path.patch | 87 +++++++++++++++++--
 1 file changed, 78 insertions(+), 9 deletions(-)

I'm dubious about the [OE-Specific] tag in patch metadata, although it
sure would not be acceptable upstream as-is :)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch b/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
index b01b8647c9..98d85eab5d 100644
--- a/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
+++ b/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
@@ -1,27 +1,30 @@ 
-Upstream-Status: Pending
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-
-From 61b00e1e051e367f5483d7b5253b6c85a9e8a90f Mon Sep 17 00:00:00 2001
+From 0570fe02c07244a8724c1e6c0437f893c8aa8e93 Mon Sep 17 00:00:00 2001
 From: Martin Kelly <mkelly@xevo.com>
 Date: Fri, 19 May 2017 00:22:57 -0700
-Subject: [PATCH] llvm: allow env override of exe path
+Subject: [PATCH 2/2] llvm: allow env override of exe path
 
 When using a native llvm-config from inside a sysroot, we need llvm-config to
 return the libraries, include directories, etc. from inside the sysroot rather
 than from the native sysroot. Thus provide an env override for calling
 llvm-config from a target sysroot.
 
+To let it work in multilib environment, we need to provide a knob to supply
+multilib dirname as well
+
+Upstream-Status: Inappropriate [OE-Specific]
+
 Signed-off-by: Martin Kelly <mkelly@xevo.com>
 Signed-off-by: Khem Raj <raj.khem@gmail.com>
+Signed-off-by: Arsalan H. Awan <Arsalan_Awan@mentor.com>
 ---
- llvm/tools/llvm-config/llvm-config.cpp | 7 +++++++
- 1 file changed, 7 insertions(+)
+ llvm/tools/llvm-config/llvm-config.cpp | 35 ++++++++++++++++++++++---------
+ 1 file changed, 25 insertions(+), 10 deletions(-)
 
 diff --git a/llvm/tools/llvm-config/llvm-config.cpp b/llvm/tools/llvm-config/llvm-config.cpp
-index 7ef7c46a262..a4f7ed82c7b 100644
+index bec89fef98c..91b4d6e4c43 100644
 --- a/llvm/tools/llvm-config/llvm-config.cpp
 +++ b/llvm/tools/llvm-config/llvm-config.cpp
-@@ -225,6 +225,13 @@ Typical components:\n\
+@@ -226,6 +226,13 @@ Typical components:\n\
  
  /// Compute the path to the main executable.
  std::string GetExecutablePath(const char *Argv0) {
@@ -35,3 +38,69 @@  index 7ef7c46a262..a4f7ed82c7b 100644
    // This just needs to be some symbol in the binary; C++ doesn't
    // allow taking the address of ::main however.
    void *P = (void *)(intptr_t)GetExecutablePath;
+@@ -306,7 +313,7 @@ int main(int argc, char **argv) {
+   // bin dir).
+   sys::fs::make_absolute(CurrentPath);
+   CurrentExecPrefix =
+-      sys::path::parent_path(sys::path::parent_path(CurrentPath)).str();
++      sys::path::parent_path(sys::path::parent_path(sys::path::parent_path(CurrentPath))).str();
+ 
+   // Check to see if we are inside a development tree by comparing to possible
+   // locations (prefix style or CMake style).
+@@ -329,40 +336,47 @@ int main(int argc, char **argv) {
+   std::string ActivePrefix, ActiveBinDir, ActiveIncludeDir, ActiveLibDir,
+               ActiveCMakeDir;
+   std::string ActiveIncludeOption;
++  // Hack for Yocto: we need to override the multilib path when we are using
++  // llvm-config from within a target sysroot.
++  std::string Multilibdir = std::getenv("YOCTO_ALTERNATE_MULTILIB_NAME");
++  if (Multilibdir.empty()) {
++    Multilibdir = "/lib/llvm10.0.1" LLVM_LIBDIR_SUFFIX;
++  }
++
+   if (IsInDevelopmentTree) {
+-    ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include";
++    ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include/llvm10.0.1";
+     ActivePrefix = CurrentExecPrefix;
+ 
+     // CMake organizes the products differently than a normal prefix style
+     // layout.
+     switch (DevelopmentTreeLayout) {
+     case CMakeStyle:
+-      ActiveBinDir = ActiveObjRoot + "/bin";
+-      ActiveLibDir = ActiveObjRoot + "/lib" + LLVM_LIBDIR_SUFFIX;
++      ActiveBinDir = ActiveObjRoot + "/bin/llvm10.0.1";
++      ActiveLibDir = ActiveObjRoot + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX;
+       ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
+       break;
+     case CMakeBuildModeStyle:
+       // FIXME: Should we consider the build-mode-specific path as the prefix?
+       ActivePrefix = ActiveObjRoot;
+-      ActiveBinDir = ActiveObjRoot + "/" + build_mode + "/bin";
++      ActiveBinDir = ActiveObjRoot + "/" + build_mode + "/bin/llvm10.0.1";
+       ActiveLibDir =
+-          ActiveObjRoot + "/" + build_mode + "/lib" + LLVM_LIBDIR_SUFFIX;
++          ActiveObjRoot + "/" + build_mode + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX;
+       // The CMake directory isn't separated by build mode.
+       ActiveCMakeDir =
+-          ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX + "/cmake/llvm";
++          ActivePrefix + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX + "/cmake/llvm";
+       break;
+     }
+ 
+     // We need to include files from both the source and object trees.
+     ActiveIncludeOption =
+-        ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot + "/include");
++        ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot + "/include/llvm10.0.1");
+   } else {
+     ActivePrefix = CurrentExecPrefix;
+-    ActiveIncludeDir = ActivePrefix + "/include";
++    ActiveIncludeDir = ActivePrefix + "/include/llvm10.0.1";
+     SmallString<256> path(StringRef(LLVM_TOOLS_INSTALL_DIR));
+     sys::fs::make_absolute(ActivePrefix, path);
+     ActiveBinDir = path.str();
+-    ActiveLibDir = ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX;
++    ActiveLibDir = ActivePrefix + Multilibdir;
+     ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
+     ActiveIncludeOption = "-I" + ActiveIncludeDir;
+   }

Comments

Khem Raj Oct. 8, 2020, 4:42 p.m.
I do not like the llvm version to the x.y.z accuracy being hardcoded
in code, this is going to be error prone whenever we update recipe. I
wonder if we can replace it with LLVM_VERSION_STRING

On Thu, Oct 8, 2020 at 3:39 AM Yann Dirson <yann.dirson@blade-group.com> wrote:
>
> From: Yann Dirson <yann@blade-group.com>
>
> Newer llvm versions have changed the logic for finding libraries,
> which prevents Mesa from building with PACKAGECONFIG[gallium-llvm]:
>
> The problem is visible in mesa/do_configure with this in local.conf:
>
>     PACKAGECONFIG_append_pn-mesa += " gallium-llvm"
>     require conf/multilib.conf
>     MULTILIBS = "multilib:lib32"
>     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
>
> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937
>
> This patch comes from meta-amd#dunfell for llvm-9.0.1, adapted for llvm-10.0.1.
>
> Signed-off-by: Yann Dirson <yann@blade-group.com>
> ---
>  ...-llvm-allow-env-override-of-exe-path.patch | 87 +++++++++++++++++--
>  1 file changed, 78 insertions(+), 9 deletions(-)
>
> I'm dubious about the [OE-Specific] tag in patch metadata, although it
> sure would not be acceptable upstream as-is :)
>
> diff --git a/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch b/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> index b01b8647c9..98d85eab5d 100644
> --- a/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> +++ b/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> @@ -1,27 +1,30 @@
> -Upstream-Status: Pending
> -Signed-off-by: Khem Raj <raj.khem@gmail.com>
> -
> -From 61b00e1e051e367f5483d7b5253b6c85a9e8a90f Mon Sep 17 00:00:00 2001
> +From 0570fe02c07244a8724c1e6c0437f893c8aa8e93 Mon Sep 17 00:00:00 2001
>  From: Martin Kelly <mkelly@xevo.com>
>  Date: Fri, 19 May 2017 00:22:57 -0700
> -Subject: [PATCH] llvm: allow env override of exe path
> +Subject: [PATCH 2/2] llvm: allow env override of exe path
>
>  When using a native llvm-config from inside a sysroot, we need llvm-config to
>  return the libraries, include directories, etc. from inside the sysroot rather
>  than from the native sysroot. Thus provide an env override for calling
>  llvm-config from a target sysroot.
>
> +To let it work in multilib environment, we need to provide a knob to supply
> +multilib dirname as well
> +
> +Upstream-Status: Inappropriate [OE-Specific]
> +
>  Signed-off-by: Martin Kelly <mkelly@xevo.com>
>  Signed-off-by: Khem Raj <raj.khem@gmail.com>
> +Signed-off-by: Arsalan H. Awan <Arsalan_Awan@mentor.com>
>  ---
> - llvm/tools/llvm-config/llvm-config.cpp | 7 +++++++
> - 1 file changed, 7 insertions(+)
> + llvm/tools/llvm-config/llvm-config.cpp | 35 ++++++++++++++++++++++---------
> + 1 file changed, 25 insertions(+), 10 deletions(-)
>
>  diff --git a/llvm/tools/llvm-config/llvm-config.cpp b/llvm/tools/llvm-config/llvm-config.cpp
> -index 7ef7c46a262..a4f7ed82c7b 100644
> +index bec89fef98c..91b4d6e4c43 100644
>  --- a/llvm/tools/llvm-config/llvm-config.cpp
>  +++ b/llvm/tools/llvm-config/llvm-config.cpp
> -@@ -225,6 +225,13 @@ Typical components:\n\
> +@@ -226,6 +226,13 @@ Typical components:\n\
>
>   /// Compute the path to the main executable.
>   std::string GetExecutablePath(const char *Argv0) {
> @@ -35,3 +38,69 @@ index 7ef7c46a262..a4f7ed82c7b 100644
>     // This just needs to be some symbol in the binary; C++ doesn't
>     // allow taking the address of ::main however.
>     void *P = (void *)(intptr_t)GetExecutablePath;
> +@@ -306,7 +313,7 @@ int main(int argc, char **argv) {
> +   // bin dir).
> +   sys::fs::make_absolute(CurrentPath);
> +   CurrentExecPrefix =
> +-      sys::path::parent_path(sys::path::parent_path(CurrentPath)).str();
> ++      sys::path::parent_path(sys::path::parent_path(sys::path::parent_path(CurrentPath))).str();
> +
> +   // Check to see if we are inside a development tree by comparing to possible
> +   // locations (prefix style or CMake style).
> +@@ -329,40 +336,47 @@ int main(int argc, char **argv) {
> +   std::string ActivePrefix, ActiveBinDir, ActiveIncludeDir, ActiveLibDir,
> +               ActiveCMakeDir;
> +   std::string ActiveIncludeOption;
> ++  // Hack for Yocto: we need to override the multilib path when we are using
> ++  // llvm-config from within a target sysroot.
> ++  std::string Multilibdir = std::getenv("YOCTO_ALTERNATE_MULTILIB_NAME");
> ++  if (Multilibdir.empty()) {
> ++    Multilibdir = "/lib/llvm10.0.1" LLVM_LIBDIR_SUFFIX;
> ++  }
> ++
> +   if (IsInDevelopmentTree) {
> +-    ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include";
> ++    ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include/llvm10.0.1";
> +     ActivePrefix = CurrentExecPrefix;
> +
> +     // CMake organizes the products differently than a normal prefix style
> +     // layout.
> +     switch (DevelopmentTreeLayout) {
> +     case CMakeStyle:
> +-      ActiveBinDir = ActiveObjRoot + "/bin";
> +-      ActiveLibDir = ActiveObjRoot + "/lib" + LLVM_LIBDIR_SUFFIX;
> ++      ActiveBinDir = ActiveObjRoot + "/bin/llvm10.0.1";
> ++      ActiveLibDir = ActiveObjRoot + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX;
> +       ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
> +       break;
> +     case CMakeBuildModeStyle:
> +       // FIXME: Should we consider the build-mode-specific path as the prefix?
> +       ActivePrefix = ActiveObjRoot;
> +-      ActiveBinDir = ActiveObjRoot + "/" + build_mode + "/bin";
> ++      ActiveBinDir = ActiveObjRoot + "/" + build_mode + "/bin/llvm10.0.1";
> +       ActiveLibDir =
> +-          ActiveObjRoot + "/" + build_mode + "/lib" + LLVM_LIBDIR_SUFFIX;
> ++          ActiveObjRoot + "/" + build_mode + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX;
> +       // The CMake directory isn't separated by build mode.
> +       ActiveCMakeDir =
> +-          ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX + "/cmake/llvm";
> ++          ActivePrefix + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX + "/cmake/llvm";
> +       break;
> +     }
> +
> +     // We need to include files from both the source and object trees.
> +     ActiveIncludeOption =
> +-        ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot + "/include");
> ++        ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot + "/include/llvm10.0.1");
> +   } else {
> +     ActivePrefix = CurrentExecPrefix;
> +-    ActiveIncludeDir = ActivePrefix + "/include";
> ++    ActiveIncludeDir = ActivePrefix + "/include/llvm10.0.1";
> +     SmallString<256> path(StringRef(LLVM_TOOLS_INSTALL_DIR));
> +     sys::fs::make_absolute(ActivePrefix, path);
> +     ActiveBinDir = path.str();
> +-    ActiveLibDir = ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX;
> ++    ActiveLibDir = ActivePrefix + Multilibdir;
> +     ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
> +     ActiveIncludeOption = "-I" + ActiveIncludeDir;
> +   }
> --
> 2.28.0
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#143135): https://lists.openembedded.org/g/openembedded-core/message/143135
Mute This Topic: https://lists.openembedded.org/mt/77380677/3617530
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [oe-patchwork@oe-patch.openembedded.org]
-=-=-=-=-=-=-=-=-=-=-=-
yann.dirson@blade-group.com Oct. 9, 2020, 8:36 a.m.
Good point.

While taking care of this however, I realized they also hardcoded the
result of a s/lib/lib64/.

That's especially puzzling as they also check for
YOCTO_ALTERNATE_MULTILIB_NAME in env,
which seems to solve the problem for mesa only, but adds to the confusion
with the following:

  std::string Multilibdir = std::getenv("YOCTO_ALTERNATE_MULTILIB_NAME");
  if (Multilibdir.empty()) {
    Multilibdir = "/lib64/llvm" LLVM_VERSION_STRING LLVM_LIBDIR_SUFFIX;
  }

... so for mesa we have Multilibdir = "/lib64" and for the rest we have
Multilibdir = "/lib64/llvm10.0.1"

I don't think there's any sanity in this either.  What about instead going
with getenv("base_libdir"),
and using Multilibdir all over where they're hardcoding "lib64" ?
What does YOCTO_ALTERNATE_MULTILIB_NAME bring over base_libdir ?

Le jeu. 8 oct. 2020 à 18:43, Khem Raj <raj.khem@gmail.com> a écrit :

> I do not like the llvm version to the x.y.z accuracy being hardcoded
> in code, this is going to be error prone whenever we update recipe. I
> wonder if we can replace it with LLVM_VERSION_STRING
>
> On Thu, Oct 8, 2020 at 3:39 AM Yann Dirson <yann.dirson@blade-group.com>
> wrote:
> >
> > From: Yann Dirson <yann@blade-group.com>
> >
> > Newer llvm versions have changed the logic for finding libraries,
> > which prevents Mesa from building with PACKAGECONFIG[gallium-llvm]:
> >
> > The problem is visible in mesa/do_configure with this in local.conf:
> >
> >     PACKAGECONFIG_append_pn-mesa += " gallium-llvm"
> >     require conf/multilib.conf
> >     MULTILIBS = "multilib:lib32"
> >     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> >
> > See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937
> >
> > This patch comes from meta-amd#dunfell for llvm-9.0.1, adapted for
> llvm-10.0.1.
> >
> > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > ---
> >  ...-llvm-allow-env-override-of-exe-path.patch | 87 +++++++++++++++++--
> >  1 file changed, 78 insertions(+), 9 deletions(-)
> >
> > I'm dubious about the [OE-Specific] tag in patch metadata, although it
> > sure would not be acceptable upstream as-is :)
> >
> > diff --git
> a/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> b/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> > index b01b8647c9..98d85eab5d 100644
> > ---
> a/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> > +++
> b/meta/recipes-devtools/llvm/llvm/0007-llvm-allow-env-override-of-exe-path.patch
> > @@ -1,27 +1,30 @@
> > -Upstream-Status: Pending
> > -Signed-off-by: Khem Raj <raj.khem@gmail.com>
> > -
> > -From 61b00e1e051e367f5483d7b5253b6c85a9e8a90f Mon Sep 17 00:00:00 2001
> > +From 0570fe02c07244a8724c1e6c0437f893c8aa8e93 Mon Sep 17 00:00:00 2001
> >  From: Martin Kelly <mkelly@xevo.com>
> >  Date: Fri, 19 May 2017 00:22:57 -0700
> > -Subject: [PATCH] llvm: allow env override of exe path
> > +Subject: [PATCH 2/2] llvm: allow env override of exe path
> >
> >  When using a native llvm-config from inside a sysroot, we need
> llvm-config to
> >  return the libraries, include directories, etc. from inside the sysroot
> rather
> >  than from the native sysroot. Thus provide an env override for calling
> >  llvm-config from a target sysroot.
> >
> > +To let it work in multilib environment, we need to provide a knob to
> supply
> > +multilib dirname as well
> > +
> > +Upstream-Status: Inappropriate [OE-Specific]
> > +
> >  Signed-off-by: Martin Kelly <mkelly@xevo.com>
> >  Signed-off-by: Khem Raj <raj.khem@gmail.com>
> > +Signed-off-by: Arsalan H. Awan <Arsalan_Awan@mentor.com>
> >  ---
> > - llvm/tools/llvm-config/llvm-config.cpp | 7 +++++++
> > - 1 file changed, 7 insertions(+)
> > + llvm/tools/llvm-config/llvm-config.cpp | 35
> ++++++++++++++++++++++---------
> > + 1 file changed, 25 insertions(+), 10 deletions(-)
> >
> >  diff --git a/llvm/tools/llvm-config/llvm-config.cpp
> b/llvm/tools/llvm-config/llvm-config.cpp
> > -index 7ef7c46a262..a4f7ed82c7b 100644
> > +index bec89fef98c..91b4d6e4c43 100644
> >  --- a/llvm/tools/llvm-config/llvm-config.cpp
> >  +++ b/llvm/tools/llvm-config/llvm-config.cpp
> > -@@ -225,6 +225,13 @@ Typical components:\n\
> > +@@ -226,6 +226,13 @@ Typical components:\n\
> >
> >   /// Compute the path to the main executable.
> >   std::string GetExecutablePath(const char *Argv0) {
> > @@ -35,3 +38,69 @@ index 7ef7c46a262..a4f7ed82c7b 100644
> >     // This just needs to be some symbol in the binary; C++ doesn't
> >     // allow taking the address of ::main however.
> >     void *P = (void *)(intptr_t)GetExecutablePath;
> > +@@ -306,7 +313,7 @@ int main(int argc, char **argv) {
> > +   // bin dir).
> > +   sys::fs::make_absolute(CurrentPath);
> > +   CurrentExecPrefix =
> > +-
> sys::path::parent_path(sys::path::parent_path(CurrentPath)).str();
> > ++
> sys::path::parent_path(sys::path::parent_path(sys::path::parent_path(CurrentPath))).str();
> > +
> > +   // Check to see if we are inside a development tree by comparing to
> possible
> > +   // locations (prefix style or CMake style).
> > +@@ -329,40 +336,47 @@ int main(int argc, char **argv) {
> > +   std::string ActivePrefix, ActiveBinDir, ActiveIncludeDir,
> ActiveLibDir,
> > +               ActiveCMakeDir;
> > +   std::string ActiveIncludeOption;
> > ++  // Hack for Yocto: we need to override the multilib path when we are
> using
> > ++  // llvm-config from within a target sysroot.
> > ++  std::string Multilibdir =
> std::getenv("YOCTO_ALTERNATE_MULTILIB_NAME");
> > ++  if (Multilibdir.empty()) {
> > ++    Multilibdir = "/lib/llvm10.0.1" LLVM_LIBDIR_SUFFIX;
> > ++  }
> > ++
> > +   if (IsInDevelopmentTree) {
> > +-    ActiveIncludeDir = std::string(LLVM_SRC_ROOT) + "/include";
> > ++    ActiveIncludeDir = std::string(LLVM_SRC_ROOT) +
> "/include/llvm10.0.1";
> > +     ActivePrefix = CurrentExecPrefix;
> > +
> > +     // CMake organizes the products differently than a normal prefix
> style
> > +     // layout.
> > +     switch (DevelopmentTreeLayout) {
> > +     case CMakeStyle:
> > +-      ActiveBinDir = ActiveObjRoot + "/bin";
> > +-      ActiveLibDir = ActiveObjRoot + "/lib" + LLVM_LIBDIR_SUFFIX;
> > ++      ActiveBinDir = ActiveObjRoot + "/bin/llvm10.0.1";
> > ++      ActiveLibDir = ActiveObjRoot + "/lib/llvm10.0.1" +
> LLVM_LIBDIR_SUFFIX;
> > +       ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
> > +       break;
> > +     case CMakeBuildModeStyle:
> > +       // FIXME: Should we consider the build-mode-specific path as the
> prefix?
> > +       ActivePrefix = ActiveObjRoot;
> > +-      ActiveBinDir = ActiveObjRoot + "/" + build_mode + "/bin";
> > ++      ActiveBinDir = ActiveObjRoot + "/" + build_mode +
> "/bin/llvm10.0.1";
> > +       ActiveLibDir =
> > +-          ActiveObjRoot + "/" + build_mode + "/lib" +
> LLVM_LIBDIR_SUFFIX;
> > ++          ActiveObjRoot + "/" + build_mode + "/lib/llvm10.0.1" +
> LLVM_LIBDIR_SUFFIX;
> > +       // The CMake directory isn't separated by build mode.
> > +       ActiveCMakeDir =
> > +-          ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX + "/cmake/llvm";
> > ++          ActivePrefix + "/lib/llvm10.0.1" + LLVM_LIBDIR_SUFFIX +
> "/cmake/llvm";
> > +       break;
> > +     }
> > +
> > +     // We need to include files from both the source and object trees.
> > +     ActiveIncludeOption =
> > +-        ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot +
> "/include");
> > ++        ("-I" + ActiveIncludeDir + " " + "-I" + ActiveObjRoot +
> "/include/llvm10.0.1");
> > +   } else {
> > +     ActivePrefix = CurrentExecPrefix;
> > +-    ActiveIncludeDir = ActivePrefix + "/include";
> > ++    ActiveIncludeDir = ActivePrefix + "/include/llvm10.0.1";
> > +     SmallString<256> path(StringRef(LLVM_TOOLS_INSTALL_DIR));
> > +     sys::fs::make_absolute(ActivePrefix, path);
> > +     ActiveBinDir = path.str();
> > +-    ActiveLibDir = ActivePrefix + "/lib" + LLVM_LIBDIR_SUFFIX;
> > ++    ActiveLibDir = ActivePrefix + Multilibdir;
> > +     ActiveCMakeDir = ActiveLibDir + "/cmake/llvm";
> > +     ActiveIncludeOption = "-I" + ActiveIncludeDir;
> > +   }
> > --
> > 2.28.0
> >
> >
> > 
> >
>