- User Since
- Aug 15 2016, 6:00 AM (88 w, 3 d)
Tue, Apr 24
Mon, Apr 9
I've based this change on an earlier fix to lldb when that project started using LLVMTestingSupport.
Sun, Apr 8
I think you'd want a definition list instead then. But I haven't tested if they can be nested inside option lists.
Sat, Apr 7
W dniu nie, 08.04.2018 o godzinie 00∶13 +0000, użytkownik Zachary Turner
Well, my idea was to list the standards one per line (like on GCC manpage), and then the '(deprecated)' comments would probably stand out enough to apply to a single line. Also, FWICS the gcc manpage simply lists which aliases are deprecated in the description text. But skipping them entirely also works for me.
To be honest, I find those '(deprecated)' confusing — the user may mistakenly assume that it's about all values rather than the alias.
Works fine, thanks a lot! Note that I haven't tested crossdev or anything special, just regular multilib.
I'm sorry, I see the problem now — the diff generated by Phabricator does not include the empty files x_x (seriously, this thing keeps surprising me in how broken it could be). I'm going to try again with correct file set tonight or tomorrow. If you could send the complete patch (preferably -p1 if you have one) to mgorny AT gentoo.org, that would also be helpful.
Fri, Apr 6
Well, it's better:
To be honest, I don't really know. But since we're not installing it straight to /usr, I suppose that's not a problem we need to solve right now.
Thu, Apr 5
Ok, that's a problem. I think we really ought to consider all possibilites of sysroot first, and either do not fall back to main system at all or do that only if sysroot doesn't have any install at all. Basically, it is important that we don't break non-Gentoo sysroots, even when running on top of Gentoo.
Ok, I've tried it on top of clang-6.0.0 and I get the following test failures:
Wed, Apr 4
If that's not a problem, then the more tests, the merrier ;-). Preferably something specific to crossdev would be helpful, given this is a new use case, and/or something that would actually have directory mismatches with CURRENT entry name (i.e. that wouldn't have worked before).
Thanks. Besides that one tiny nit, looks good at a first glance. I'll test it tomorrow or the next day (but only for the most basic use, sorry).
Thu, Mar 29
Mar 20 2018
Mar 19 2018
Mar 15 2018
Mar 12 2018
Aye, sorry, I confused it with generated config ;-). It looks sane to me.
I don't see why not but I'm not sure if it has any value by itself. FWICS, LLVM_DYLIB_COMPONENTS is not used anywhere in cmake/*.
Yes, full standalone.
I can't test this right now but please make sure not to break linking to split shared libraries without dylib.
Mar 8 2018
Thanks for the review. As for the -Wl,-z,origin part, I'd rather leave that alone unless we have a clear indication that either it is not necessary for any of the supported FreeBSD and DragonFly BSD versions, or that it can be passed unconditionally without breaking any of the supported systems (and which linkers accept it).
Mar 6 2018
@rnk, could you confirm the rebased patch? I'm not sure if I should override InputKind::RenderScript as well.
Mar 5 2018
Mar 2 2018
Ping. I'd like to have this reviewed before I roll 6.0.0 final for Gentoo.
Feb 26 2018
Feb 24 2018
@beanz, updated as requested.
Feb 23 2018
Feb 19 2018
Ping for the third time.
Jan 29 2018
Jan 20 2018
Jan 19 2018
Disclaimer: I have never seen a plugin for LLDB. I've just noticed the wrong path in strace output and fixed it ;-).
Jan 18 2018
Jan 9 2018
Jan 7 2018
Updated the patch to use LLVM_ENABLE_ZLIB directly.
I was talking of:
Jan 6 2018
Well, it's actually more complex. In Gentoo we want to let the user choose whether he wants to build against zlib or without zlib support. So in the end there are two uses to be considered:
Maybe we could. I presumed people are using the separate variables for some reason. We'd have to check that it's properly sanitized when building in-tree and given to cmake though.
Jan 4 2018
Dec 13 2017
Dec 11 2017
Nov 30 2017
Nov 27 2017
Updated to fix unittest failure.
Nov 25 2017
Nov 18 2017
Or even more abstract (if we assume we don't have to check for presence of llvm_tools_dir):
To be honest, as I said before, I'm entirely confused by the logic there, with all the prepending, appending and shuffling around. But if you believe it gives the correct result, I'm all for it.
Nov 17 2017
I don't see how this could break anything, and it's a pretty straightforward change.
Nov 16 2017
Please revert this commit. You've just broken all the stand-alone builds of clang.
Nov 15 2017
I'm worried that having a different first component of VERSION and SOVERSION could confuse some tools like ldconfig. I'm going to see if we can solve it via different install prefixes with RPATHs first.
Nov 14 2017
Hmm, that's an interesting option too. I was thinking of using LLVM_VERSION_SUFFIX originally but it obviously did not go to SOVERSION. Can this have any unforeseen consequences? Should VERSION become *major+suffix-0-minor* then?
We = Gentoo. What for is already described = to install libstdc++ and libc++ versions of LLVM simultaneously for rebuild period. How long = for the time being, or until we find a better working solution.