[libcxx-dev] [RFC] A vision for building the runtimes
Martin Storsjö via libcxx-dev
libcxx-dev at lists.llvm.org
Fri Oct 23 11:52:57 PDT 2020
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
More information about the libcxx-dev
mailing list