| Message ID | 20250515130753.326236-1-luca.fancellu@arm.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | clang: Include the libclang python bindings in the build | expand |
On Thu, 15 May 2025 at 15:08, luca fancellu via lists.openembedded.org <luca.fancellu=arm.com@lists.openembedded.org> wrote: > Modify the clang recipe to provide also the python module > 'clang' when building libclang. Why? Can that be a PACKAGECONFIG? Alex
Hi Alex, > On 15 May 2025, at 14:10, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 15 May 2025 at 15:08, luca fancellu via lists.openembedded.org > <luca.fancellu=arm.com@lists.openembedded.org> wrote: >> Modify the clang recipe to provide also the python module >> 'clang' when building libclang. > > Why? Can that be a PACKAGECONFIG? I used the same approach as lldb, why do you think we should use a different approach? Cheers, Luca
On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> wrote: > > Why? Can that be a PACKAGECONFIG? > > I used the same approach as lldb, why do you think we should use a different approach? The request was to explain why this is beneficial, and should be always enabled. What is the use case specifically in clang? Alex
Hi Alex > On 15 May 2025, at 14:38, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> wrote: >>> Why? Can that be a PACKAGECONFIG? >> >> I used the same approach as lldb, why do you think we should use a different approach? > > The request was to explain why this is beneficial, and should be > always enabled. What is the use case specifically in clang? ok I see what you mean, the module will use some python bindings for libclang, so I guess some recipe could switch the feature on if using the module, otherwise it should stay off by default. Make sense, I’ll try to implement in that way Cheers, Luca
On Thu, May 15, 2025 at 6:52 AM luca fancellu via lists.openembedded.org <luca.fancellu=arm.com@lists.openembedded.org> wrote: > > Hi Alex > > > On 15 May 2025, at 14:38, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > > > On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> wrote: > >>> Why? Can that be a PACKAGECONFIG? > >> > >> I used the same approach as lldb, why do you think we should use a different approach? > > > > The request was to explain why this is beneficial, and should be > > always enabled. What is the use case specifically in clang? > > ok I see what you mean, the module will use some python bindings for libclang, so I guess > some recipe could switch the feature on if using the module, otherwise it should stay off > by default. > > Make sense, I’ll try to implement in that way Just measure build times before and after this change, my guess is it is not adding a significant amount, but do measure it. > > Cheers, > Luca > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#216680): https://lists.openembedded.org/g/openembedded-core/message/216680 > Mute This Topic: https://lists.openembedded.org/mt/113126509/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Hi Khem, > On 15 May 2025, at 16:47, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > On Thu, May 15, 2025 at 6:52 AM luca fancellu via > lists.openembedded.org <luca.fancellu=arm.com@lists.openembedded.org> > wrote: >> >> Hi Alex >> >>> On 15 May 2025, at 14:38, Alexander Kanavin <alex.kanavin@gmail.com> wrote: >>> >>> On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> wrote: >>>>> Why? Can that be a PACKAGECONFIG? >>>> >>>> I used the same approach as lldb, why do you think we should use a different approach? >>> >>> The request was to explain why this is beneficial, and should be >>> always enabled. What is the use case specifically in clang? >> >> ok I see what you mean, the module will use some python bindings for libclang, so I guess >> some recipe could switch the feature on if using the module, otherwise it should stay off >> by default. >> >> Make sense, I’ll try to implement in that way > > Just measure build times before and after this change, my guess is it > is not adding a significant amount, but do measure it. Is there a standard way to do that? Otherwise I’ll do just: time bitbake -c build <recipe> Let me know. Cheers, Luca
On Thu, May 15, 2025 at 11:48 AM Luca Fancellu <Luca.Fancellu@arm.com> wrote: > > Hi Khem, > > > On 15 May 2025, at 16:47, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > On Thu, May 15, 2025 at 6:52 AM luca fancellu via > > lists.openembedded.org <luca.fancellu=arm.com@lists.openembedded.org> > > wrote: > >> > >> Hi Alex > >> > >>> On 15 May 2025, at 14:38, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > >>> > >>> On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> wrote: > >>>>> Why? Can that be a PACKAGECONFIG? > >>>> > >>>> I used the same approach as lldb, why do you think we should use a different approach? > >>> > >>> The request was to explain why this is beneficial, and should be > >>> always enabled. What is the use case specifically in clang? > >> > >> ok I see what you mean, the module will use some python bindings for libclang, so I guess > >> some recipe could switch the feature on if using the module, otherwise it should stay off > >> by default. > >> > >> Make sense, I’ll try to implement in that way > > > > Just measure build times before and after this change, my guess is it > > is not adding a significant amount, but do measure it. > > Is there a standard way to do that? enable buildstats and do a build before and after it should capture task times > > Otherwise I’ll do just: time bitbake -c build <recipe> > > Let me know. > > Cheers, > Luca >
Hi Khem, > On 15 May 2025, at 20:38, Khem Raj <raj.khem@gmail.com> wrote: > > On Thu, May 15, 2025 at 11:48 AM Luca Fancellu <Luca.Fancellu@arm.com> wrote: >> >> Hi Khem, >> >>> On 15 May 2025, at 16:47, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: >>> >>> On Thu, May 15, 2025 at 6:52 AM luca fancellu via >>> lists.openembedded.org <luca.fancellu=arm.com@lists.openembedded.org> >>> wrote: >>>> >>>> Hi Alex >>>> >>>>> On 15 May 2025, at 14:38, Alexander Kanavin <alex.kanavin@gmail.com> wrote: >>>>> >>>>> On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> wrote: >>>>>>> Why? Can that be a PACKAGECONFIG? >>>>>> >>>>>> I used the same approach as lldb, why do you think we should use a different approach? >>>>> >>>>> The request was to explain why this is beneficial, and should be >>>>> always enabled. What is the use case specifically in clang? >>>> >>>> ok I see what you mean, the module will use some python bindings for libclang, so I guess >>>> some recipe could switch the feature on if using the module, otherwise it should stay off >>>> by default. >>>> >>>> Make sense, I’ll try to implement in that way >>> >>> Just measure build times before and after this change, my guess is it >>> is not adding a significant amount, but do measure it. >> >> Is there a standard way to do that? > > enable buildstats and do a build before and after > it should capture task times Here a summary, let me know if I should paste a particular task/tasks: with: NOTE: Build completion summary: NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_deploy_source_date_epoch: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_package_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_recipe_qa: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_populate_lic: 0.0% sstate reuse(0 setscene, 1 scratch) Host Info: Linux <hostname> 6.5.0-25-generic #25~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2 x86_64 x86_64 Build Started: 1747340234.36 Elapsed time: 1484.02 seconds CPU usage: 71.1% without: NOTE: Build completion summary: NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_deploy_source_date_epoch: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_create_package_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_recipe_qa: 0.0% sstate reuse(0 setscene, 1 scratch) NOTE: do_populate_lic: 0.0% sstate reuse(0 setscene, 1 scratch) Host Info: Linux <hostname> 6.5.0-25-generic #25~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2 x86_64 x86_64 Build Started: 1747338659.83 Elapsed time: 1294.93 seconds CPU usage: 81.6% Cheers, Luca
On Thu, May 15, 2025 at 1:57 PM Luca Fancellu <Luca.Fancellu@arm.com> wrote: > Hi Khem, > > > On 15 May 2025, at 20:38, Khem Raj <raj.khem@gmail.com> wrote: > > > > On Thu, May 15, 2025 at 11:48 AM Luca Fancellu <Luca.Fancellu@arm.com> > wrote: > >> > >> Hi Khem, > >> > >>> On 15 May 2025, at 16:47, Khem Raj via lists.openembedded.org > <raj.khem=gmail.com@lists.openembedded.org> wrote: > >>> > >>> On Thu, May 15, 2025 at 6:52 AM luca fancellu via > >>> lists.openembedded.org <luca.fancellu=arm.com@lists.openembedded.org> > >>> wrote: > >>>> > >>>> Hi Alex > >>>> > >>>>> On 15 May 2025, at 14:38, Alexander Kanavin <alex.kanavin@gmail.com> > wrote: > >>>>> > >>>>> On Thu, 15 May 2025 at 15:36, Luca Fancellu <Luca.Fancellu@arm.com> > wrote: > >>>>>>> Why? Can that be a PACKAGECONFIG? > >>>>>> > >>>>>> I used the same approach as lldb, why do you think we should use a > different approach? > >>>>> > >>>>> The request was to explain why this is beneficial, and should be > >>>>> always enabled. What is the use case specifically in clang? > >>>> > >>>> ok I see what you mean, the module will use some python bindings for > libclang, so I guess > >>>> some recipe could switch the feature on if using the module, > otherwise it should stay off > >>>> by default. > >>>> > >>>> Make sense, I’ll try to implement in that way > >>> > >>> Just measure build times before and after this change, my guess is it > >>> is not adding a significant amount, but do measure it. > >> > >> Is there a standard way to do that? > > > > enable buildstats and do a build before and after > > it should capture task times > > Here a summary, let me know if I should paste a particular task/tasks: > > with: > > NOTE: Build completion summary: > NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_deploy_source_date_epoch: 0.0% sstate reuse(0 setscene, 1 > scratch) > NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_create_package_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_recipe_qa: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_populate_lic: 0.0% sstate reuse(0 setscene, 1 scratch) > > Host Info: Linux <hostname> 6.5.0-25-generic #25~22.04.1-Ubuntu SMP > PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2 x86_64 x86_64 > Build Started: 1747340234.36 > Elapsed time: 1484.02 seconds > CPU usage: 71.1% > > > without: > > NOTE: Build completion summary: > NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_deploy_source_date_epoch: 0.0% sstate reuse(0 setscene, 1 > scratch) > NOTE: do_create_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_create_package_spdx: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_recipe_qa: 0.0% sstate reuse(0 setscene, 1 scratch) > NOTE: do_populate_lic: 0.0% sstate reuse(0 setscene, 1 scratch) > > Host Info: Linux <hostname> 6.5.0-25-generic #25~22.04.1-Ubuntu SMP > PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2 x86_64 x86_64 > Build Started: 1747338659.83 > Elapsed time: 1294.93 seconds > CPU usage: 81.6% So it does seem to add 200s to build time perhaps make it a packageconfig > > > Cheers, > Luca > >
On 15 May 2025, at 22:13, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote:
> So it does seem to add 200s to build time perhaps make it a packageconfig
Doing buildstats comparisons is less than trivial. I just replicated the test, ensuring that there’s no noise caused by other recipes being built:
clang-native do_compile 9.3s +1.2% 806.2s -> 815.5s
I’m fine with adding a PACKAGECONFIG but I think it should be on by default. I know we’re trying to reduce the clang build time but 9s is basically noise in this context.
Ross
Hi Khem and Alex > On 16 May 2025, at 10:56, Ross Burton <Ross.Burton@arm.com> wrote: > > On 15 May 2025, at 22:13, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: >> So it does seem to add 200s to build time perhaps make it a packageconfig > > Doing buildstats comparisons is less than trivial. I just replicated the test, ensuring that there’s no noise caused by other recipes being built: > > clang-native do_compile 9.3s +1.2% 806.2s -> 815.5s > > I’m fine with adding a PACKAGECONFIG but I think it should be on by default. I know we’re trying to reduce the clang build time but 9s is basically noise in this context. > please let me know how to proceed, PACKAGECONFIG and config enabled by default or disabled, I’ll send the v2 shortly. Cheers, Luca
On Fri, May 16, 2025 at 5:46 AM Luca Fancellu <Luca.Fancellu@arm.com> wrote: > Hi Khem and Alex > > > On 16 May 2025, at 10:56, Ross Burton <Ross.Burton@arm.com> wrote: > > > > On 15 May 2025, at 22:13, Khem Raj via lists.openembedded.org <raj.khem= > gmail.com@lists.openembedded.org> wrote: > >> So it does seem to add 200s to build time perhaps make it a > packageconfig > > > > Doing buildstats comparisons is less than trivial. I just replicated the > test, ensuring that there’s no noise caused by other recipes being built: > > > > clang-native do_compile 9.3s +1.2% 806.2s > -> 815.5s > > > > I’m fine with adding a PACKAGECONFIG but I think it should be on by > default. I know we’re trying to reduce the clang build time but 9s is > basically noise in this context. > > > I agree if this is the new number let’s apply it as is > > please let me know how to proceed, PACKAGECONFIG and config enabled by > default or disabled, I’ll send the v2 shortly. > > Cheers, > Luca > >
diff --git a/meta/recipes-devtools/clang/clang_git.bb b/meta/recipes-devtools/clang/clang_git.bb index b41b700292c7..6634eb5416b6 100644 --- a/meta/recipes-devtools/clang/clang_git.bb +++ b/meta/recipes-devtools/clang/clang_git.bb @@ -163,6 +163,7 @@ EXTRA_OECMAKE += "-DLLVM_ENABLE_ASSERTIONS=OFF \ -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON \ -DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS_TO_BUILD}' \ -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD='${LLVM_EXPERIMENTAL_TARGETS_TO_BUILD}' \ + -DCLANG_PYTHON_BINDINGS_VERSIONS='${PYTHON_BASEVERSION}' \ " EXTRA_OECMAKE:append:class-native = "\ @@ -312,7 +313,7 @@ PROVIDES:append:class-native = " llvm-native libclc-native" PROVIDES:append:class-target = " llvm libclc" PROVIDES:append:class-nativesdk = " nativesdk-llvm nativesdk-libclc" -PACKAGES =+ "${PN}-libllvm ${PN}-lldb-python ${PN}-libclang-cpp ${PN}-tidy ${PN}-format ${PN}-tools ${PN}-clc \ +PACKAGES =+ "${PN}-libllvm ${PN}-lldb-python ${PN}-libclang-python ${PN}-libclang-cpp ${PN}-tidy ${PN}-format ${PN}-tools ${PN}-clc \ libclang lldb lldb-server liblldb llvm-linker-tools" @@ -342,6 +343,8 @@ FILES:${PN}-libclang-cpp = "${libdir}/libclang-cpp.so.*" FILES:${PN}-lldb-python = "${libdir}/python*/site-packages/lldb/*" +FILES:${PN}-libclang-python = "${libdir}/python*/site-packages/clang/*" + FILES:${PN}-tidy = "${bindir}/*clang-tidy*" FILES:${PN}-format = "${bindir}/*clang-format*"
Modify the clang recipe to provide also the python module 'clang' when building libclang. Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> --- meta/recipes-devtools/clang/clang_git.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)