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

[Alexis Murzeau]

Hi,

Le 05/03/2020 à 01:12, Nicholas D Steeves a écrit :
> Hi Lisandro,
> 
> Lisandro Damián Nicanor Pérez Meyer <perezmeyer at gmail.com> writes:
> 
>> Hi!
>>
>> On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves <nsteeves at gmail.com> wrote:
>>>
>>> Hi Lisandro,
>>>
>>> Out of curiosity, could this be solved for a Debian (and derivatives)
>>> context by changing the Recommends on clang and clang-tidy to their
>>> versioned package names (eg: clang-8 and clang-tidy-8)?
>>
>> No, this is not a versioning problem.
>>
> 
> I agree, ideally it should be solved upstream, but a side-effect of
> installing Recommends s/clang/clang-8/ is that it pulls in a dependency
> on libclang-common-8-dev, and
> [...]>
> My proposal would solve the Debian (and derivatives) case and is easy to
> update/maintain with a sed regex.  Is our team categorically opposed to
> working around upstream issues using Debian packaging facilities?
> 


When the recommends on clang was added, the changelog got this:
```
 * Make qtcreator recommend clang, as it has added quite interesting tools
    that use it.

```

So I think the recommends is just a way so the user has recommended
tools available to qtcreator the same way `make` is recommended to build
a C/C++ project.

This is only a recommendation as the user may not want to use clang
stuff and just use, say, gcc and ninja instead for example.


I still think there should be a Depends (not Recommends) on
libclang-common-8-dev instead somewhere. (that is, directly from
qtcreator or indirectly)

This to ensure the clang code model of QtCreator (and perhaps other IDEs
that use it) works correctly and find its *builtin headers*.

Again, I emphasis on builtin headers as I do not talk about API headers
here; libclang's API headers are in a different package: libclang-8-dev.
See also my previous mail:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952718#70

@Lisandro, what do you think now given we were not talking about the
same headers before ?

-- 
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/20200314/c4a54ec0/attachment-0001.sig>