clang: Allow conditional compilation of clangd

[lorenzph]

clangd should not be needed in target builds. Extend PACKAGECONFIG to enable selective disabling and disable it by default for target builds.

Additionally, this enables compilation of clang-native on Debian "bullseye" hosts where GCC 10 fails to compile clangd with an internal compilation error.

---

Contributor checklist

• [x] Changes have been tested
• [x] Signed-off-by is present
• [x] The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

[quaresmajose]

it looks like target is replaced by native on the commit message. looking at the code the clangd is disabled for class-target builds and not for native.

clangd is not needed for -native builds. Extend PACKAGECONFIG to enable
selective disabling and disable it by default for native builds.

[lorenzph]

it looks like target is replaced by native on the commit message. looking at the code the clangd is disabled for class-target builds and not for native.

clangd is not needed for -native builds. Extend PACKAGECONFIG to enable
selective disabling and disable it by default for native builds.

My bad... Fixed.

[lorenzph]

@kraj: Are the build logs of the CI run available somewhere (based on the log output it doesn't look like the CI failure is caused by this change but I'd like to make sure)?

[kraj]

@kraj: Are the build logs of the CI run available somewhere (based on the log output it doesn't look like the CI failure is caused by this change but I'd like to make sure)?

they are right in github actions link above. Click on 'details'

[lorenzph]

@kraj: Are the build logs of the CI run available somewhere (based on the log output it doesn't look like the CI failure is caused by this change but I'd like to make sure)?

they are right in github actions link above. Click on 'details'

I meant the detailed logs of the bitbake run (or I am simply failing to find the right link :-)). The logs from https://github.com/kraj/meta-clang/actions/runs/7899722329/attempts/2?pr=912:

 Traceback (most recent call last):
  File "/home/khem/actions-runner-meta-clang/_work/meta-clang/meta-clang/yoe/sources/poky/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
    return func(*args, **kwargs)
  File "/home/khem/actions-runner-meta-clang/_work/meta-clang/meta-clang/yoe/sources/poky/meta/lib/oeqa/runtime/cases/parselogs.py", line 185, in test_parselogs
    self.assertEqual(errcount, 0, msg=self.msg)
AssertionError: 1 != 0 : Log: /home/khem/actions-runner-meta-clang/_work/meta-clang/meta-clang/yoe/build/tmp/work/qemuarm64-yoe-linux/yoe-sdk-image/1.0/target_logs/postinstall.log
-----------------------
Central error: * opkg_cmd_exec: Command failed to capture privilege lock: Resource temporarily unavailable.
***********************
 * opkg_lock: Could not lock /run/opkg.lock: Resource temporarily unavailable.
 * opkg_cmd_exec: Command failed to capture privilege lock: Resource temporarily unavailable.

sounds like the failure is unrelated to change (but there is a chance that the issue leading up to this would be visible from the bitbake logs).

[kraj]

@kraj: Are the build logs of the CI run available somewhere (based on the log output it doesn't look like the CI failure is caused by this change but I'd like to make sure)?

they are right in github actions link above. Click on 'details'

I meant the detailed logs of the bitbake run (or I am simply failing to find the right link :-)). The logs from https://github.com/kraj/meta-clang/actions/runs/7899722329/attempts/2?pr=912:

 Traceback (most recent call last):
  File "/home/khem/actions-runner-meta-clang/_work/meta-clang/meta-clang/yoe/sources/poky/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
    return func(*args, **kwargs)
  File "/home/khem/actions-runner-meta-clang/_work/meta-clang/meta-clang/yoe/sources/poky/meta/lib/oeqa/runtime/cases/parselogs.py", line 185, in test_parselogs
    self.assertEqual(errcount, 0, msg=self.msg)
AssertionError: 1 != 0 : Log: /home/khem/actions-runner-meta-clang/_work/meta-clang/meta-clang/yoe/build/tmp/work/qemuarm64-yoe-linux/yoe-sdk-image/1.0/target_logs/postinstall.log
-----------------------
Central error: * opkg_cmd_exec: Command failed to capture privilege lock: Resource temporarily unavailable.
***********************
 * opkg_lock: Could not lock /run/opkg.lock: Resource temporarily unavailable.
 * opkg_cmd_exec: Command failed to capture privilege lock: Resource temporarily unavailable.

sounds like the failure is unrelated to change (but there is a chance that the issue leading up to this would be visible from the bitbake logs).

thats is bitbake run ( actually runtime logs in qemuarm64 ), however, this failure is known, it happens when more than one qemu instance is running same test case, it happens rarely but happens. I have started another run and see if it goes through.