[PATCH] D20992: [CMake] Add LLVM runtimes directory

Saleem Abdulrasool via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 24 19:00:11 PDT 2016


On Fri, Jun 24, 2016 at 6:03 PM, Chris Bieneman <beanz at apple.com> wrote:

>
> On Jun 24, 2016, at 5:49 PM, Saleem Abdulrasool <compnerd at compnerd.org>
> wrote:
>
> On Tue, Jun 21, 2016 at 2:37 PM, Chris Bieneman via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> beanz updated this revision to Diff 61451.
>> beanz added a comment.
>>
>> I kinda went a bit off into the woods after the llvm-dev thread, and I
>> think I came back with something either interesting or insane... you decide.
>>
>> This patch changed a few things about how I'm handling the runtimes
>> subdirectory. First, it handles the compiler-rt builtin library dependency
>> by building the builtins first as their own external project call. Second,
>> it glumps all the other runtime libraries (including compiler-rt's
>> sanitizers) into a single external project by using the
>> runtimes/CMakeLists.txt file as the top-level CMake.
>>
>
> Is the intent that the sanitizer runtimes and the C++ runtime would be a
> single project?
>
>
> Not really one project. What it does is disconnect the configure-time and
> build-time dependencies. The builtins are configured and built first and
> separately. Then the remaining runtimes can be configured in a single
> group, and built respecting the dependencies across project boundaries.
>
> Does that make sense?
>

Ah, the configuration step.  That make sense.  There is a large overlap
between them, so it make sense to configure the set as a whole, especially
when you consider the fact that each build of them should run in a similar
environment.

Thanks for the explanation!


> -Chris
>
>   If so, that seems a bit imprecise.  However, this is engineering, and if
> it does result in a more maintainable system, it may be worth it.  The
> builtins definitely need to be pulled out into a separate project.  It
> feels like the right layering here would be something like:
>
> builtins
> unwind
> sanitizers
> libc++abi / libc++
>
> This is interesting for a few reasons. The biggest is a potential for
>> reduced CMake-overhead when building runtime libraries. Additionally it
>> will allow cross-project dependencies to be  more easily modeled in CMake
>> because the runtime libraries will be able to be aware of the targets
>> coming from other runtime projects.
>>
>> Thoughts?
>>
>>
>> http://reviews.llvm.org/D20992
>>
>> Files:
>>   CMakeLists.txt
>>   cmake/modules/LLVMExternalProjectUtils.cmake
>>   runtimes/CMakeLists.txt
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160624/c3582178/attachment.html>


More information about the llvm-commits mailing list