<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jul 25, 2016 at 12:28 PM Sylvestre Ledru <<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hello,<br>
<br>
+Andrew and Brad who did most of the work on cmake.<br>
To be honest, I am not a cmake expert, any help to improve the
situation is appreciated.</div></div><div bgcolor="#FFFFFF" text="#000000"><div><br>
<br>
Le 23/07/2016 à 23:42, Paweł Bylica a écrit :<br>
</div></div><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">Hi LLVM,
<div><br>
</div>
<div>I complained about the deb packages couple of times
previously, even fixed some issues in packaging. I'm mostly
interested in having reliable share cmake files available in
llvm-dev packages. The version 3.7 was fine, but 3.8+ have
regressions. <br>
</div>
<div><br>
</div>
<div>I'm not here to blame anybody. I would like to identify the
issues and discuss long term solutions.</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
Sure, thanks for doing that! <br></div><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I started with building very simple test framework that
checks different Ubuntu/Debian versions and currently
supported LLVM versions. The first and only test just checks
find_package(LLVM CONFIG) cmake function.</div>
<div><a href="https://github.com/chfast/llvm-apt-tests/blob/master/CMakeLists.txt" target="_blank">https://github.com/chfast/llvm-apt-tests/blob/master/CMakeLists.txt</a><br>
</div>
<div><br>
</div>
<div>I've tested {3.8, 3.9, 4.0} x {xenial, jessie} using docker
images and Travis CI.</div>
<div><a href="https://travis-ci.org/chfast/llvm-apt-tests/builds/146508275" target="_blank">https://travis-ci.org/chfast/llvm-apt-tests/builds/146508275</a><br>
</div>
<div>As you can see, only the 3.8 on Jessie passed the test.</div>
<div><br>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
Nice work! I am not surprised that 3.8 is passing the test, this is
the one I focused the most.<br>
Brad reported this bug <a href="https://llvm.org/bugs/show_bug.cgi?id=28325" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=28325</a>
for 3.9 and 4.0<br>
I just applied them to the branches (I was in holidays before)<br>
<br>
Do you mind if I steal that and I add this to my CI to test that we
don't regress? or are you planning to maintain it?</div></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>No problem, you can steal whatever you want. What CI do you have in mind? I could join in and help maintaining it there.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
<blockquote type="cite">
<div dir="ltr">
<div>Issues I've identified:</div>
<div>
<ol>
<li>Packaging adds version prefix to binaries, directories,
etc. -- eg. llc is renamed to llc-3.8. I'm not sure how it
is done, but maybe we should add support for such feature
to LLVM's cmake?</li>
</ol>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
This is done in debian/rules, by creating symlink
<a href="http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/snapshot/debian/rules?revision=2020&view=markup#l319" target="_blank">http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/snapshot/debian/rules?revision=2020&view=markup#l319</a>
<br>
We do that to make sure that the different version of llvm/clang are
co-installable. llc and others are provided by this llvm defaults (
<a href="https://packages.qa.debian.org/l/llvm-defaults.html" target="_blank">https://packages.qa.debian.org/l/llvm-defaults.html</a> ).<br>
Having this available upstream would be good but this hasn't been a
source of troubles in the past.</div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>Default install location for cmake shared files is
<prefix>/lib/llvm/share/llvm/cmake. find_package()
is not able to find them there as it is non-standard path.
find_package() needs a hint, like setting LLVM_DIR
variable as in <a href="https://github.com/chfast/llvm-apt-tests/blob/master/configure.sh#L6" target="_blank">https://github.com/chfast/llvm-apt-tests/blob/master/configure.sh#L6</a><br>
If we moved the cmake shared files to
<prefix>/lib/llvm/cmake no hint would be needed.</li>
</ol>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
This should be fixed</div><div bgcolor="#FFFFFF" text="#000000"><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li>On Ubuntu, packaging script moves cmake shared files to
<prefix>/share/llvm-X.Y/cmake. I'm guessing to solve
the issue (2). find_package() is able to find
LLVMConfig.cmake file without any hint, but this file
contains absolute paths referencing previous locations of
other files. You usually get issues like this one:<br>
<span style="line-height:1.5"><br>
CMake Error at
/usr/share/llvm-3.8/cmake/LLVMConfig.cmake:181
(include):<br>
</span><span style="line-height:1.5">include could not
find load file:<br>
/usr/share/llvm/cmake/LLVM-Config.cmake</span><br>
<br>
<span style="line-height:1.5">Maybe it is good idea to
include other cmake files assuming there are located
next to the main file instead of relying on </span>absolute<span style="line-height:1.5"> paths.</span></li>
</ol>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
This is probably related to llvm-defaults behavior.</div><div bgcolor="#FFFFFF" text="#000000"><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li><span style="line-height:1.5">It's a bit </span>weird
Debian and Ubuntu packages has different layout of
installed shared files.</li>
</ol>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
I don't think it is the case. I am not making any changes in Ubuntu
packages. In some cases, Ubuntu official packages are patched from
Debian's but patches are usually forwarded to me.</div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I've rechecked. You are right, however Ubuntu packages it differently, but we should not care about that. I have to modify my test config to force installing llvm-3.8-dev from <a href="http://apt.llvm.org" target="_blank">apt.llvm.org</a>.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<ol>
<li><span style="line-height:1.5">Packages 3.9+ does not
have any cmake's shared files, just empty dirs where
those files are supposed to be. That might be a bug in
the latest packaging script. </span></li>
</ol>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
Could you report a bug?<br></div></blockquote><div><br></div><div>I think I was wrong about that too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Thanks for the feedback, this is appreciated!</div></blockquote><div><br></div><div>Sorry for late answer, was on holidays and busy with other projects. I will try proceed with the idea to move cmake shared files withing LLVM dir structure.</div><div><br></div><div>- Paweł</div></div></div></div>