kraj/meta-clang

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

Lorac opened this issue · 14 comments

Lorac commented

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 commented

@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 commented

@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 commented

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

Lorac commented

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 commented

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

Lorac commented

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

kraj commented

@Lorac can you try the proposed fix in #674

Lorac commented

@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 commented

@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 commented
Lorac commented

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

kraj commented

Help me with backport of you can

  • 👍1
Lorac commented

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 commented

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?