Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

[Alexis Murzeau]

Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi!
> 
> El mié., 4 mar. 2020 18:11, Alexis Murzeau <amubtdx at gmail.com> escribió:
> 
>> Hi,
>>
>> I've a question about whether libclang1-X should depend on
>> libclang-common-X-dev to always have the clang's builtin headers
>> available when libclang is installed.
>>
> 
> Definitely not. Headers should depend upon the library, not the other way
> around.
> 
>>
> 

Why do you think that ?



My view on this is that libclang contains the compiler and the compiler
needs the headers but the headers don't really need the compiler to be used.
I agree that if you install the headers, you probably have to install
clang to use them anyway.

But actually, clang binaries (like clang-tidy) depends on
libclang-common-X-dev which depends on libllvm (that one is different
than libclang. libllvm is the backend of the compiler while libclang and
clang are the frontend)

So as of now, headers do not depends on libclang or clang, and clang
depends on these headers but not libclang.

clang also depends on libclang, as do QtCreator and kdevelop and other
IDE using libclang.

That's why I'm wondering if the dependency of clang-X =>
libclang-common-X-dev should be lifted to libclang1-X =>
libclang-common-X-dev.
For clang, this would start from:
clang-8 =>
    libclang1-8
    libclang-common-8-dev
to:
clang-8 =>
    libclang1-8 =>
        libclang-common-8-dev

The description of libclang1-X is:
The C Interface to Clang provides a relatively small API that exposes
facilities for:
- parsing source code into an abstract syntax tree (AST),
- loading already-parsed ASTs,
- traversing the AST,
- associating physical source locations with elements within the AST,
- and other facilities that support Clang-based development tools.

Some of them (like the one using already parsed AST) might not need
builtin headers, so it might be understandable to avoid a dependency
from libclang1 to libclang-common-X-dev.

binary rdepends on libclang1-{6.0,7,8} are:
 - doxygen
 - clang-X which also depends already on libclang-common-X-dev
 - clang-tools-X which also depends on clang
 - libclang-X-dev which also depends already on libclang-common-X-dev
 - bpftrace (high-level tracing language for Linux eBPF)
 - codelite (IDE for C, C++ and others)
 - gnat-ps (IDE for C and Ada)
 - gnome-builder which also depends on clang (IDE for C, C++ and others)
 - irony-server (Emacs C/C++ minor mode)
 - kdevelop which recommends clang (C/C++ IDE)
 - libclang-perl (libclang perl bindings)
 - qdoc-qt5 (tool to generate doc from C/C++ source files)
 - qtcreator which recommends clang (C/C++ IDE)
 - rtags which recommends libclang-common-X-dev (C/C++ client/server
indexer with integration for Emacs)
 - shiboken2 (CPython bindings generator for C++ libraries)
 - ycmd which recommends libclang-common-X-dev (code-completion &
comprehension server)

So many of them uses libclang to parse C/C++ code, but only bpftrace do
not I think (it parses the BPFTrace language instead which is based on C).

If libclang1-X should not depend on libclang-common-X-dev, then users of
libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
code from source should depend themselves on libclang-common-X-dev as it
is required for them to work correctly.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-llvm-team/attachments/20200304/6a7cd19d/attachment-0001.sig>