[llvm-dev] [libcxx-dev] [RFC] A vision for building the runtimes

[Martin Storsjö via llvm-dev]

On Fri, 23 Oct 2020, Louis Dionne wrote:

>
>> On Oct 23, 2020, at 06:09, Martin Storsjö <martin at martin.st> wrote:
>>
>> Hi,
>>
>> One thing I'm left wanting in this setup, is that for various reasons 
>> I've currently been passing different sets of extra flags (compiler and 
>> linker flags) to each of libunwind/libcxxabi/libcxx. Some of it is 
>> included in the patch I'll post soon, reducing the need for it though. 
>> But I've been building e.g. libunwind with 
>> -Wno-dll-attribute-on-redeclaration, but not the other libs. (Yes if 
>> that's a permanent setup, I should probably upstream setting that flag 
>> as well.)
>
> Why doesn't this flag apply to all the runtimes?

Normally you'd want to make sure that declarations and definitions have 
matching dllimport/export attributes. But in libunwind, there are such 
attributes (set via _LIBUNWIND_EXPORT) on the definitions, but not on the 
declarations in unwind.h (which is more or less equivalent to the 
standard-ish unwind.h shipped as part of clang). Fixing it would be mostly 
unnecessary churn, as it isn't really an issue in this particular case, so 
it's easiest to just disable the warning for libunwind.

But for other runtimes (that generally are clean in the aspect that the 
warning checks) we want the warning enabled, as it would point out 
deviations.

So TL;DR I should just upstream it.

>>
>> But for general cases, when trying out various build setups, being able to pass individual CMAKE_CXX_FLAGS or CMAKE_SHARED_LINKER_FLAGS to each of libunwind/libcxxabi/libcxx would be very useful, especially if doing something that isn't necessarily supported (yet).
>
> I believe the correct place for that is in a downstream-only patch being 
> applied to your fork of llvm. That's how we do it at Apple, and it 
> avoids having to maintain all kinds of hooks to customize X and Y 
> upstream. I'm not saying these hooks don't even make sense -- they make 
> sense most of the time. But if we can avoid adding an option to 
> customize all the flags for each runtime, I think that would be ideal.

I try hard to avoid downstream patches on top of LLVM in my builds - and 
try to resolve a fix that is acceptable upstream, but for this aspect I've 
been lazy when it's been easy to work around it by just passing extra 
cmake flags.

>> On Oct 23, 2020, at 06:44, Martin Storsjö <martin at martin.st> wrote:
>>
>> On Thu, 22 Oct 2020, Louis Dionne via libcxx-dev wrote:
>>
>>> - Monorepo
>>>   This is the "easy" and most common way to build the runtimes. It builds the runtimes as subprojects of LLVM (with LLVM_ENABLE_PROJECTS), with the same compiler that's used to build LLVM.
>>
>> Btw, unrelated to the topic at hand, but related to monorepo builds in general, as I've brought up some time before - it'd be great for various reasons to be able to do such a build (building the tools, not the runtimes) by pointing cmake directly at the llvm-project root instead of at the llvm subdir.
>>
>> Last time this was brought up, Chris [1] mentioned that it'd be doable, but would require a bit of work to make the produced files (<builddir>/bin/clang etc) end up in the root of the build dir, instead of in a subdir, like <builddir>/llvm/bin/clang. My cmake-fu is a bit too weak to easily pinpoint what needs to be fixed to proceed with this though...
>
> Interesting -- I also brought this up recently: 
> http://lists.llvm.org/pipermail/llvm-dev/2020-June/142384.html
>
> However, the issue I've been hitting with this is that it's a huge chunk 
> of work to bite. Making the runtimes work only is something I can chew, 
> but it's another story entirely to make it work for arbitrary 
> sub-projects.

Actually, this sounds like a slightly different thing than what I was 
getting at.

I still wanted it to behave as if llvm was the root project, and only for 
building tools, not runtimes, so just like LLVM_ENABLE_PROJECTS today. But 
for cmake/ccache reasons I'd want to have all built code reside in 
directories below the main cmake root dir. (I rely heavily on such ccache 
effects to make the compile times more bearable.) If enabling e.g. clang 
now via LLVM_ENABLE_PROJECTS, clang's source is referred to as ../clang. 
To avoid this, I still symlink it into llvm/tools.

(The backstory is that as long as the source is under the cmake root 
directory, it's referred to with relative paths, so any filename that ends 
up in the build product, e.g. in assert messages, are identical if 
building in two separate checkouts, and can share ccache objects. If 
source files are outside of the main cmake root dir, they are referred to 
with an absolute path, which breaks the ccache sharing.)

// Martin