[cfe-dev] Small patches to allow fully independent clang/llvm/compiler-rt/libc++

C Bergström via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 14 06:52:39 PDT 2015


On Wed, Oct 14, 2015 at 8:47 PM, Jonathan Roelofs
<jonathan at codesourcery.com> wrote:
>
>
> On 10/14/15 7:11 AM, Vasileios Kalintiris wrote:
>>>
>>> Some people may disagree on the principle, even if it doesn't affect
>>> current builds. But I'll let them voice their concerns.
>>
>>
>> IMHO, the "correct" approach for a GNU-free/independent clang package
>> requires
>> a new ToolChain class for LLVM-based toolchains. Maybe, this class could
>> inherit from the Linux ToolChain and use most of the existing
>> infrastructure
>> for paths, options & tools invocations. Otherwise, we could use these
>> configuration-time options for most of the GNU-dependencies that we want
>> to
>> replace. However, I think that we would be duplicating
>> effort/functionality
>> at two different places (cmake & clang source code). Additionally, other
>> than
>> compiler-rt, libcxx, libcxxabi, etc., we'd need a non-GLIBC/GNU C library
>> which might have a different set of CRT files with its own naming scheme
>> for the
>> dynamic linker/loader.
>
>
> Something along these ^ lines is the "correct" way to do it. You'd have to
> add your own vendor to Triple.h, and then specialize these defaults based on
> seeing that particular vendor.  Baking these decisions in at compile-time is
> an anti-pattern driver-wise.
>
> If you do it this way, then you'll be able to write testcases for your
> changes, and those tests will get run by all the buildbots (not just one
> configured to have one particular set of defaults).  This has the added
> benefit of not requiring more builders to test more configurations.
>
> Please don't commit these patches as-is.

Can you give precise feedback about what's wrong with the patches
(as-is)? I'd like to "fix" them. Is it philosophical or something
wrong?



More information about the cfe-dev mailing list