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

[Jonathan Roelofs via cfe-dev]

On 10/14/15 7:52 AM, C Bergström wrote:
> 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?

To re-phrase, I think the "spirit" behind clang-01.diff, clang-02.diff 
and clang-03.diff are contrary to the design goals of the driver. I 
think you ought to re-work them so that they don't touch CMakeLists.txt 
at all, that way all of these defaults are set at compiler runtime via 
the vendor part of the triple (or some flag(s)), not at compiler 
compiletime.

I'm not sure I'm the best person to review clang-04.diff, but at the 
very least it needs testcases.


Jon

>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded