<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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.<br>
      <br>
      Le 23/07/2016 à 23:42, Paweł Bylica a écrit :<br>
    </div>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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>
    Sure, thanks for doing that! <br>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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 moz-do-not-send="true"
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 moz-do-not-send="true"
            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>
    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 class="moz-txt-link-freetext" href="https://llvm.org/bugs/show_bug.cgi?id=28325">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?<br>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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>
    This is done in debian/rules, by creating symlink
<a class="moz-txt-link-freetext" href="http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/snapshot/debian/rules?revision=2020&view=markup#l319">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 class="moz-txt-link-freetext" href="https://packages.qa.debian.org/l/llvm-defaults.html">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.<br>
    <br>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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 moz-do-not-send="true"
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>
    This should be fixed<br>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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>
    This is probably related to llvm-defaults behavior.<br>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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>
    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.<br>
    <blockquote
cite="mid:CAE7VtSesiG0+sNC-Xyd+8j4oYuurNefdeUh_zhD_gTZrSntHxA@mail.gmail.com"
      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>
    Could you report a bug?<br>
    <br>
    Thanks for the feedback, this is appreciated!<br>
    <br>
    Sylvestre<br>
    <p><br>
    </p>
  </body>
</html>