clang-tools-extra into a seperate package without clang compiler for sdk

[Lorac]

Is your feature request related to a problem? Please describe. I would like to have clang-tools-extra in a separate package so that I can install those tools without clang itself into an SDK. One issue I ran into is that if I include meta-clang layer, mesa will now build with llvm provided by meta-clang instead of poky.

With CLANGSDK = 0 if we are using mesa with gallium-llvm, the compiler is still present in the SDK.

Describe the solution you'd like I would like to be able to install inside an SDK something like nativesdk-clang-tools-extra without the clang compiler, etc.

Describe alternatives you've considered The current workaround is to override the current override for the PACKAGECONFIG[gallium-llvm] to restore the one from poky mesa recipe.

We have to redefine the YOCTO_ALTERNATE_EXE_PATH to the original mesa from poky instead of the one from meta-clang.

re-override mesa in our layer

PACKAGECONFIG[gallium-llvm] = "-Dllvm=enabled -Dshared-llvm=enabled, -Dllvm=disabled, llvm${MESA_LLVM_RELEASE} llvm-native \
                               elfutils"

export YOCTO_ALTERNATE_EXE_PATH = "${STAGING_LIBDIR}/llvm${MESA_LLVM_RELEASE}/llvm-config"

override on clang

PROVIDES:remove = "llvm llvm-native"
PROVIDES:remove:class-native = " llvm-native"

[kraj]

@Lorac CLANGSDK controls the cross tools not the target packages. gallium-llvm pulls in target clang correctly, but perhaps we can improve by creating more fine grained output packages out of target clang recipe, where the libllvm is packages separately and libclang separately, so you have better control over packaging needed pieces with more granularity.

We build clang/clang-tools-extra together in a combined tree. If you only prefer to use it partially, perhaps fine grained packaging is the answer here too.

core layer just builds llvm where as meta-clang builds both clang+llvm, and if you are using meta-clang its better to use the version from meta-clang since that will be more uptodate and in sync with clang compiler which you intend to use.

Overall, I think if we consider packaging changes suggested above, it should fit your needs and you wont need the workarounds.

[Lorac]

@kraj In the best case scenario for us if I can do something like this:

TOOLCHAIN_HOST_TASK += " \
    nativesdk-clang-tools-extra \
"

And only install stuff from that target.

At the moment I tried something like this:

PACKAGE_BEFORE_PN:append = "clang-tools-extra"
RDEPENDS:clang-tools-extra:append = " ${PN}-libllvm libclang python3"

FILES:libclang = "\
  ${libdir}/libclang.so.*\
"

FILES:clang-tools-extra = " \
    ${bindir}/clang-tidy \
    ${bindir}/run-clang-tidy \
    ${bindir}/clang-format \
"

But for some reason, it will pull the clang compiler anyway and I haven't figured why yet.

[kraj]

check the shared libraries that clang-tidy needs. Perhaps it depends on libclang. bitbake -g might be able to show the depchain.

[Lorac]

clang-tidy depends on libclang and libllvm, but when running bitbake -g it doesn't help with PACKAGES, afaik. It just tells me that my meta-toolchain recipe requires nativesdk-clang which makes sense because I added:

TOOLCHAIN_HOST_TASK += " \
    nativesdk-clang-tools-extra \
"

But that specific package doesn't require the clang compiler itself, just the .so.

[kraj]

OK CLANGSDK="0" in local.conf perhaps will help in removing the direct RDEPENDS in nativesdk-packagegroup-sdk-host

[Lorac]

CLANGSDK is already at 0. This is why it's the most confusing.

[kraj]

@Lorac can you try the proposed fix in https://github.com/kraj/meta-clang/pull/674

[Lorac]

@kraj looks good, but I haven't tested it yet. I wonder why the clang-tidy package doesn't RDEPENDS on libllvm libclang. When you look at libraries that clang-tidy links to, libllvm and libclang are present. I'll be away for a couple of days so I can't test it now. Is it possible to backport changes to kirkstone since it's an LTS for poky?

I think clang-apply-replacements is needed for clang-tidy. Or at least, afaik run-clang-tidy can use it to apply replacements.

Another subject, maybe another issue to talk about, can kirkstone branch be supported with newer version of clang too?

[kraj]

@Lorac its deps are looking right to me here

PV = 15.0.2
PR = r0
PKGR = r0.8
RPROVIDES =
RDEPENDS = clang-libclang-cpp (>= 15.0.2) clang-libllvm (>= 15.0.2) libcxx (>= 15.0.2) musl (>= 1.2.3+git1+dc9285ad1d)
RRECOMMENDS =
PKGSIZE = 27658533
FILES = /usr/bin/*clang-tidy*
FILELIST = /usr/bin/clang-tidy /usr/bin/run-clang-tidy

I am all for backporting this change to kirkstone, regarding clang15 it might be a bit involved process since compiler has changed a lot and all packages may not compile so perhaps creating a separate branch kirkstone_clang15 or somesuch and then maturing it might be the way to go.

for clang-apply-replacements its perhaps better to install clang-tools in sdk as well or maybe create a RRECOMMENDS for it in clang-tidy package

[Lorac]

Interesting output is that oe-pkg-util script?

If you are doing a kirkstone_clang15 are you going to do a kirkstone_clang16 too. When to stop? Or it’s more of an experiment and when kirkstone_clang15 is stable enough it will merge in kirkstone?

I agree that the rrecommends is probably a good idea for clang-tidy and clang-apply-replacement.

On Fri, Oct 7, 2022 at 14:06 Khem Raj @.***> wrote:

@Lorac https://github.com/Lorac its deps are looking right to me here

PV = 15.0.2 PR = r0 PKGR = r0.8 RPROVIDES = RDEPENDS = clang-libclang-cpp (>= 15.0.2) clang-libllvm (>= 15.0.2) libcxx (>= 15.0.2) musl (>= 1.2.3+git1+dc9285ad1d) RRECOMMENDS = PKGSIZE = 27658533 FILES = /usr/bin/clang-tidy FILELIST = /usr/bin/clang-tidy /usr/bin/run-clang-tidy

I am all for backporting this change to kirkstone, regarding clang15 it might be a bit involved process since compiler has changed a lot and all packages may not compile so perhaps creating a separate branch kirkstone_clang15 or somesuch and then maturing it might be the way to go.

for clang-apply-replacements its perhaps better to install clang-tools in sdk as well or maybe create a RRECOMMENDS for it in clang-tidy package

— Reply to this email directly, view it on GitHub https://github.com/kraj/meta-clang/issues/672#issuecomment-1271891463, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKUK2F7LCCWBQ2EJEQNWSLWCBRBNANCNFSM6AAAAAAQ5Y5DNY . You are receiving this because you were mentioned.Message ID: @.***>

[Lorac]

@kraj When do you think the changes will be available to kirkstone?

[kraj]

Help me with backport of you can

[Lorac]

Help me with backport of you can

I'll be testing the backported change onto kirkstone branch and will submit it when I confirm it works.

[Lorac]

When I install

    nativesdk-clang-tidy \
    nativesdk-clang-format \

To the SDK, ./sysroots/x86_64-ekosdk-linux/usr/bin/clang is present inside the native sdk.

There is ./lib/clang/14.0.3/include/mmintrin.h headers file too that are not necessary, if I don't want the clang compiler.

Want me to open another issue?