1 |
That seems a lot like what we've already done. I guess a GSOC student is working on the libcxxabi piece. The only advantage to using our runtime, libcxxrt, is performance and code size. |
2 |
|
3 |
Original Message |
4 |
From: Lei Zhang |
5 |
Sent: Friday, August 19, 2016 06:34 |
6 |
To: gentoo-dev@l.g.o |
7 |
Reply To: gentoo-dev@l.g.o |
8 |
Cc: gentoo-dev-announce@l.g.o |
9 |
Subject: Re: [gentoo-dev] New project: LLVM |
10 |
|
11 |
2016-08-18 21:56 GMT+08:00 C Bergström <cbergstrom@×××××××××.com>: |
12 |
> @mgorny may be able to help with some of this and has quite a bit of |
13 |
> experience building clang/llvm. Where I work we use a "wrapper" that |
14 |
> helps coordinate a lot of the moving pieces. |
15 |
> |
16 |
> https://github.com/pathscale/llvm-suite/ |
17 |
> |
18 |
> This may not be the perfect "gentoo" way to handle it, but the |
19 |
> approach would produce a clean and correct compiler. With llvm |
20 |
> dependencies getting more and more complicated, I'm not sure if it |
21 |
> would be possible to have both a gnu-free and also perfect |
22 |
> 1-project-source-repo:1-ebuild ratio. |
23 |
|
24 |
Currently the ebuilds for libunwind, libc++abi and libc++ all involve |
25 |
some hackery to support standalone build. And the package clang is |
26 |
just a placeholder, while it's actually built in llvm. |
27 |
|
28 |
Maybe we can put them all into the llvm package, and control what |
29 |
components to build via USE flags. |
30 |
|
31 |
|
32 |
Lei |