- User Since
- Aug 15 2016, 6:00 AM (345 w, 1 d)
Sun, Mar 26
Fri, Mar 24
Thank you. 16.x isn't affected.
This commit broke building against libclang-cpp.so dylib. I've submitted a fix as D146427 but it haven't received any attention so far.
Mon, Mar 20
Sat, Mar 18
Do you have a doc link or some precedent? Something to help us understand the implications of this.
Wed, Mar 15
Mon, Mar 13
Sun, Mar 12
First observation: third-party/unittest/UnitTestMain/CMakeLists.txt still has BUILDTREE_ONLY which makes it impossible to use this with LLVM_DISTRIBUTION_COMPONENTS. Could you adjust that as well?
Fri, Mar 10
I think it's good.
Feb 23 2023
Feb 4 2023
I haven't been able to get Halide to configure successfully yet but I already spotted something suspicious. dependencies/llvm/CMakeLists.txt does:
Jan 31 2023
Ok, this turned out to be surprisingly painless, at least within our packaging.
Jan 28 2023
While the general direction seems sound, I suspect this may be a real PITA given that for us:
Jan 24 2023
I'm sorry for reporting it this late (clang's been broken for over two weeks, so we couldn't periodically test it) but this change is causing test regressions on Gentoo/amd64:
Thanks for the superfast review! I'll push it later today.
Jan 23 2023
Jan 19 2023
Are you sure about this? FWIU right now the default is to "use Z3 if available". If I read the patch right, it will be "default to requiring Z3, unless explicitly disabled". Not that I mind but I suppose it's a semantic change.
Jan 16 2023
Jan 14 2023
Ping. Please either fix this or revert and put the new version back for review.
Jan 13 2023
This version breaks standalone builds of clang:
Jan 12 2023
It looks good to me as-is.
I think it makes sense but I'd like to get @MaskRay's opinion as well.
Jan 8 2023
Our policy is to not accept patches where nobody is willing to provide a CI bot, which is the case here currently.
I'm wondering if we shouldn't just by setting CLANG_NO_DEFAULT_CONFIG=1 like in clang's test suite rather than tying to predict how different config files will affect these tests.
Dec 26 2022
I've pushed a fix in dab67c66932b9149842f7c8431e951f952125fc0, based on @jhuber6's fix from the other diff.
Thank you. I'm going to try if the same solution helps with D139723 too.
Dec 25 2022
Also, please link commits to diffs using Differential Revision: trailer in the future.
Dec 21 2022
Use explicit mapping as requested.
Dec 19 2022
We also have the same problem for __string unless I am mistaken, @mgorny
Dec 18 2022
Thinking about it more, probably the cleanest long term solution would be to simply use .h suffix for files but that obviously won't solve the existing upgrade problem.
That question can be turned around; why should software authors need to rename their source files to work around deficiencies in package managers?
Use __tuple_dir instead of the icky __tuple2.
Dec 9 2022
Package managers track all installed files, and remove files that are no longer installed by the specific package version. However, the removal happens *after* installing the new version.
Dec 8 2022
Gentle ping. Do you have any specific requests on how this could be improved? I'd love to see the problem fixed before the next weekend (that's when I do snapshots for Gentoo).
Dec 5 2022
@MaskRay, I've reverted your M68k test fix since this change was reverted too, to get M68k tests to pass again.
Well, I'd prefer renaming them permanently but one release would be good enough for Gentoo. Alternatively, at least for private headers we could streamline this by using a distinct prefix/suffix for directories, e.g. __tuple for a file, and __tuple_dir for directory. This would probably be cleaner than temporarily appending 2.
Dec 4 2022
Well, it fixes the problem for me as well. I don't know the code but FWICS you've added the original assumption, so I guess you know best.
I've regenerated files. However, I needed to modify the generator to strip the extra 2 from public header name. That's not the prettiest solution, I admit, so I'm open to better ideas.
Dec 3 2022
Dec 2 2022
Dec 1 2022
Thanks a lot for doing this!
Closing in favor of D139107.
Nov 30 2022
Replacing a file with a directory (and the other way arond) is problematic in general. E.g. if you attempt to ninja install it on top of the existing installation:
Nov 28 2022
Nov 26 2022
Thanks. I can confirm that the two tests pass for me with this patch.
Nov 24 2022
Nov 23 2022
Nov 22 2022
@thesamesam, could you test it on PPC32, please?
@phosek, very gentle ping ;-).
Nov 21 2022
Plus there's the matter of LLVMTestingSupport library.
I'll try to test this today. I suppose the main idea would be to enable LLVM_INSTALL_GTEST, then stop unpacking third-party directory when building other packages, correct? Perhaps it would make sense to update the checks like the one in clang while doing that: