If you have been using this variable, please reply with how you have been using it.
As far as I can tell, it would only have worked if you were only using LLVM by itself without using Clang or any other LLVM projects. And even then, it would have produced an llvm-config binary that lied blatantly about where libraries were installed. So if anyone has managed to use this variable successfully, I’d love to know how.
Based on my understanding that this variable is essentially completely broken in its current form, I’m planning to commit a bunch of fixes in the next couple of days. If these break something for you, I will probably need some help understanding your configuration and host OS in order to debug and fix it. =] Reply here or to the specific commit and give me all the details you can.
That said, I’m hopeful this will make the variable significantly more useful. Notably, with all of the patches applied (and it required changing almost every subproject) I have a CMake build with every subproject checked out which passes ‘check-all’. I can also build and install lldb with its python bindings support on a multilib system where python ends up in ‘lib64/python2.7’ (for example).
I’ve not written a patch to try to intelligently set the variable to the correct value, but I’m looking at that. I first want to get the variable actually working.
If anyone maintains a buildbot on a 64-bit linux system that uses multilib, I’d love to work with you to get its configuration to set the variable in order to ensure this setup doesn’t regress in the future. It was in a pretty sorry state when I set out to fix it.
Also, I know some folks that do packaging have a lot of patches around this variable. I’m curious if the fixes I have and those patches are compatible, duplicated, or what. I don’t have any of these patches, so I can’t really speak to that. I think I’ve seen one or two before but none were really comprehensive.
Anyways, just wanted to send a note before commits started to fly…