Ping.

Ping.

I wonder if we can remove the helper variables such as PYTHON_LIBRARIES now.

In D74051#2211869, @tstellar wrote:

In D74051#2017115, @mgorny wrote:

Nevermind, I figured out good enough workaround.

What was the workaround?

Moved comment back to the top.

In D85299#2204692, @serge-sans-paille wrote:

I have some difficulties to understand the exact scenario: if one knows at compile-time that polly is needed, why no just build it as a linked-in plugin, as suggested by @Meinersbur?

In D85299#2204537, @Meinersbur wrote:

If it is passes that (like Polly) using the in-tree static plugin mechanism, I recommend using the LLVM_<plugin>_LINK_INTO_TOOLS=ON flag.

I don't really know about the two plugin mechanisms. To be honest, I haven't been able to get Polly to work yet — however, one of our users has done some testing for me, and IIRC the 'pass plugin' mechanism didn't work for some reason.

Thanks!

Do not add dylib explicitly.

In D85281#2196693, @Meinersbur wrote:

Which configurations have you tested this with?

Updated to use LLVM_LINK_LLVM_DYLIB.

I suppose this makes sense. Testing it on some more systems might be good but I guess buildbot will take care of that.

Thanks!

Is RelA an actual result of install target, or just the build tree? I think it needs to be the former.

In D84987#2186113, @MaskRay wrote:

I am not familiar with the standalone clang build. Can you share a command?

Seems to work fine for me.

This commit breaks standalone clang builds.

I suppose this makes sense and shouldn't break anything.

I'll remove my earlier protest but let's give others a chance to review.

Did you forget to include a patch that uses LIBPFM_HAS_FIELD_CYCLES?

Here's a version with the extra test.

You shouldn't be checking the running kernel but the version of the kernel headers. Think of build hosts building LLVM for an entirely different system altogether.

In D76665#2138050, @kcc wrote:

can we instead slap an attribute on these special variables?

(though personally I'd prefer just converting these three docs into .rst and having a single markup everywhere, without extra dependencies)

See D55445. Long story short, this isn't gonna happen because of license change.

Ping. The current state is that c-index-test crashes for us, and I'd like to see it fixed for 10.0.1. I have a patch of my own but it doesn't handle all that _static magic, so I guess this one's better.

Ping. It'd be nice to have this fixed.

Thanks for the fix.

This change broke standalone builds of LLD:

In D82001#2098158, @sammccall wrote:

I don't feel strongly about the inside/outside loop, let's stick with what you've proposed then.

LG with a test.

Added a test that adds a hidden option that is closer to argv. Confirmed that it fails without the change, passes with the change.

(I'm working on the test)

Ok, I don't think this failure is due to my changes but I've proposed a solution as D82001 anyway.

For the record, this seems to trigger some command-line option parser problem:

In D81922#2095834, @MaskRay wrote:

Can you please add some messages about duplicate symbols?

Is this what you had in mind? I'm sorry it took me this long to get to it again.

Added a test.

Nevermind, I figured out good enough workaround.

In D74051#2016085, @lebedev.ri wrote:

In D74051#2016078, @mgorny wrote:

This broke running clang tests stand-alone:

Traceback (most recent call last):
  File "/var/tmp/portage/sys-devel/clang-11.0.0.9999/work/x/y/clang-abi_x86_64.amd64/bin/../../llvm/utils/lit/lit/TestingConfig.py", line 89, in load_from_path
    exec(compile(data, path, 'exec'), cfg_globals, None)
  File "/var/tmp/portage/sys-devel/clang-11.0.0.9999/work/x/y/clang/test/utils/update_cc_test_checks/lit.local.cfg", line 21, in <module>
    assert os.path.isfile(script_path)
AssertionError
                                                           
FAILED: test/CMakeFiles/check-clang

Obviously this fails when LLVM source tree is not available.

Is that a supported build mode for clang?

This broke running clang tests stand-alone:

In D72109#1876189, @serge-sans-paille wrote:

@mgorny can you try with https://reviews.llvm.org/D74602 applied?

This broke standalone build of clang. It's trying to write into /include (as in, root directory) now! My guess is that LLVM_BINARY_DIR is undefined at this point of standalone build, later it might be defined to point to directory where LLVM was installed which also wouldn't be correct.

@broadwaylamb, I've requested backporting this to 10.x: https://bugs.llvm.org/show_bug.cgi?id=44905. However, i wasn't able to find to find you on Bugzilla and CC you. Could you confirm whether it's fine to backport, please?

Gentoo, using the ebuilds. I think the most relevant is how libc++abi is configured:

Added tlsbase.

This seems to have broken NetBSD:

I can confirm the tests pass both on i386 and amd64 for me, with this patch.