llvm dev - Dec 2014 - [LLVMdev] Heads up: planning to commit a significant number of fixes to LLVM_LIBDIR_SUFFIX for CMake

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...
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141228/e9562ff2/attachment.html>

Hi,

On Sun, Dec 28, 2014 at 2:37 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 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.
>
>
Using it successfully with an awful hack like this:

%if "%{_lib}" == "lib64"
# Nasty hardcoded path
sed -i
s,CLANG_RESOURCE_DIR,'"../lib64/clang/%{_release_version}"',g
tools/clang/lib/Driver/Driver.cpp
sed -i s,"/lib/LLVMgold","/lib64/LLVMgold",g
tools/clang/lib/Driver/Tools.cpp
sed -i s,"}lib{","}lib64{",g
tools/clang/test/Preprocessor/iwithprefix.c
sed -i s,'$ORIGIN/../lib','$ORIGIN/../lib64',g CMakeLists.txt
%endif

sed -i s,LLVM_LIBDIR,%{_lib}, tools/clang/lib/Driver/Driver.cpp

 Thanks for trying to fix this mess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141228/3afb36e2/attachment.html>