Bug#862328: clang-4.0: ClangConfig.cmake is broken by Debian packaging

[Sylvain Joubert]

Package: clang-4.0
Version: 1:4.0.1~+rc1-1
Severity: important

Dear Maintainer,

In the same way as #819072 and preceding issues for LLVMConfig, the Clang CMake
files are not usable with the current packaging in Debian.
While LLVMConfig.cmake can be found without issue, this is not the case for
ClangConfig.cmake

Considering the following CMake script:

cmake_minimum_required(VERSION 3.2)
project(clangconfig)
find_package(Clang REQUIRED)

one gets:

CMake Error at CMakeLists.txt:3 (find_package):
By not providing "FindClang.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Clang", but
CMake did not find one.

Could not find a package configuration file provided by "Clang" with any of
the following names:

ClangConfig.cmake
clang-config.cmake

Add the installation prefix of "Clang" to CMAKE_PREFIX_PATH or set
"Clang_DIR" to a directory containing one of the above files. If "Clang"
provides a separate development package or SDK, be sure it has been
installed.

Additionnally, when explicitly providing Clang_DIR with
/usr/share/llvm-4.0/cmake, one gets:

CMake Error at /usr/share/llvm-4.0/cmake/ClangConfig.cmake:17 (include):
include could not find load file:

/usr/lib/cmake/clang/ClangTargets.cmake
Call Stack (most recent call first):
CMakeLists.txt:3 (find_package)

I'm guessing some paths needs to be updated in order to handle the Debian
repackaging.

Sylvain



-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 'unstable'), (90, 'experimental')
Architecture: amd64
(x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clang-4.0 depends on:
ii binutils 2.28-4
ii libc6 2.24-10
ii libc6-dev 2.24-10
ii libclang-common-4.0-dev 1:4.0.1~+rc1-1
ii libclang1-4.0 1:4.0.1~+rc1-1
ii libgcc-6-dev 6.3.0-16
ii libgcc1 1:6.3.0-16
ii libjsoncpp1 1.7.4-3
ii libllvm4.0 1:4.0.1~+rc1-1
ii libobjc-6-dev 6.3.0-16
ii libstdc++-6-dev 6.3.0-16
ii libstdc++6 6.3.0-16

Versions of packages clang-4.0 recommends:
ii llvm-4.0-dev 1:4.0.1~+rc1-1
ii python 2.7.13-2

Versions of packages clang-4.0 suggests:
pn clang-4.0-doc <none>
pn gnustep <none>
pn gnustep-devel <none>

-- no debconf information

[Sylvestre Ledru]

Hello

Le 11/05/2017 à 13:26, Sylvain Joubert a écrit :
> Package: clang-4.0
> Version: 1:4.0.1~+rc1-1
> Severity: important
>
> Dear Maintainer,
>
> In the same way as #819072 and preceding issues for LLVMConfig, the Clang CMake
> files are not usable with the current packaging in Debian.
> While LLVMConfig.cmake can be found without issue, this is not the case for
> ClangConfig.cmake
>

Would you mind providing a patch for this?

Thanks
S

[Sylvain Joubert]

Package: clang-4.0
Version: 1:4.0.1~+rc1-1

Followup-For: Bug #862328

Hi,

After some digging, here is what I've come up with:

1- Dependencies

I think that ClangConfig.cmake (and the symlinks,... described above) and its
two sibling files should be provided by libclang-x.y-dev not by clang-x.y.
Most of the targets provided by this CMake file are installed with
libclang-x.y-dev so that makes much more sense (and LLVMConfig.cmake is
provided by llvm-x.y-dev)
However, some target artifacts are provided by other packages as well:
- clang (executable) by clang-x.y
- clang-format (executable) by clang-format-x.y

If these artifacts are not installed during configure, CMake will error-
complain about that.
I'm not really sure what's the best approach here but, as is, the package
providing ClangConfig.cmake must depends on clang-x.y and clang-format-x.y in
order to work.

2- Fixing find_package(Clang)

Install ClangConfig.cmake and siblings in /usr/lib/llvm-x.y/lib/cmake/clang
(instead of /usr/share/llvm-x.y/cmake)
Add a symlink /usr/share/clang-x.y/cmake -> /usr/lib/llvm-x.y/lib/cmake/clang

This matches what's done for LLVMConfig.cmake
This way find_package(Clang) can automatically find the config files.
To be consistent with LLVMConfig.cmake the symlink can instead be put in
/usr/lib/clang-x.y/cmake

3- Fixing CLANG_INSTALL_PREFIX

Apply the attached patch (fix-cmake-clang-confix.patch based on the 5.0
snapshot) to ClangConfig.cmake in the clang sources to fix the prefix location

With that ClangConfig.cmake and siblings can correctly compute the path of the
target artifacts

4- Fixing clang executable name

The targets files expect the clang executable to be named and located in
/usr/lib/llvm-x.y/bin/clang-x.y but the rules file (line 374) strips its
version suffixes.

I'm not sure why this was done but I guess we can either:
- not rename the executable (and fix /usr/bin/clang-x.y symlink and maybe
others)
- fix the ClangTargets-*.cmake file post generation to strip the version suffix


With these changes, one should be able to use the provided ClangConfig.cmake
and its targets.
I'm not really able to test that much more, nor provide a full patch for the
packaging repo but I can test any .deb that would have such fixes (including
the 5.0 snapshots).

Regards,

[Mario Lang]

Hi.

I've just been bitten by the same problem. It appears to still be an
issue even with libclang-5.0-dev. find_package(Clang) doesn't work,
also if Clang_DIR is provided.

--
CYa,
⡍⠁⠗⠊⠕

[Kim Gräsman]

Hello,

I've been banging my head against this for a while, too.

From what I can tell, Sylvain's original report is correct, there's no
way to use the Clang CMake modules in this packaging.

CMake can be convinced to find Clang with:

find_package(Clang REQUIRED CONFIG NAMES llvm Clang)

but even then it will fail with

CMake Error at /usr/share/llvm-3.9/cmake/ClangConfig.cmake:16 (include):

include could not find load file:

/usr/lib/cmake/clang/ClangTargets.cmake
Call Stack (most recent call first):

CMakeLists.txt:34 (find_package)

The failing module, ClangConfig.cmake, does:

...
set(CLANG_CMAKE_DIR "${CLANG_INSTALL_PREFIX}/lib/cmake/clang")

# Provide all our library targets to users.
include("${CLANG_CMAKE_DIR}/ClangTargets.cmake")
...

This can never match ClangTargets.cmake's true location, which is just
next to ClangConfig.cmake, in /usr/share/llvm-3.9/cmake.

I haven't had a chance to investigate Sylvain's patch, or understand
what the root cause of the problem is (Clang or packaging), but I'll
try to dig deeper.

Cheers,
- Kim

[Sylvestre Ledru]

Hello,

On 11/11/2017 22:22, Kim Gräsman wrote:
> Hello,
>
> I've been banging my head against this for a while, too.
>
> From what I can tell, Sylvain's original report is correct, there's no
> way to use the Clang CMake modules in this packaging.
>

I don't have time to work on that unfortunately for now. Any help would
be much appreciated!

Cheers,
S

[Kim Gräsman]

Hi all,

I think the most critical problem reported by Sylvain up-thread is
mostly solved, and I can't quite judge the severity of the rest:

> 1- Dependencies
>
> I think that ClangConfig.cmake (and the symlinks,... described above) and its
> two sibling files should be provided by libclang-x.y-dev not by clang-x.y.

This would be nice; I'm currently installing the Clang compiler just
to get at the CMake files required to build it. That seems backwards.
I haven't really gotten my head around the dependency cross-wiring
described by Sylvain, but maybe that needs to be solved first.

> 2- Fixing find_package(Clang)

This appears to be solved in the packaging as part of the fix for #890514. Yay!

> 3- Fixing CLANG_INSTALL_PREFIX
>
> Apply the attached patch (fix-cmake-clang-confix.patch based on the 5.0
> snapshot) to ClangConfig.cmake in the clang sources to fix the prefix location

As far as I can tell, this is also solved now --
CLANG_INSTALL_PREFIX=/usr/lib/llvm-7 on my system.

> 4- Fixing clang executable name
>
> The targets files expect the clang executable to be named and located in
> /usr/lib/llvm-x.y/bin/clang-x.y but the rules file (line 374) strips its
> version suffixes.

I don't know the status/relevance of this.

Maybe there should be new, distinct bugs for these problems?

- Kim