Hi Karlo Am Mo., 4. Nov. 2024 um 00:08 Uhr schrieb Karlo Strize via Lists.Yoctoproject.Org <karlo.strize.linux=gmail....@lists.yoctoproject.org >:
> Hi Adrian, > > Sorry, I didn't notice but in the wip.patch the ide_codium.py file is > missing. > In attachment is wip2.patch that includes all the differences. > Thank you, now I can understand what you really did. > > > Yes, that's because cmake and also meson have the compile_commands.json > generator built in. With meson it's enabled by default, with cmake we > enable this feature > here: https://git.yoctoproject.org/poky/tree/meta/classes- > recipe/cmake.bbclass#n185. > > > So if cmake compile_commands.json is generated automatically with this > OECMAKE_ARGS variable, then can I remove > > "cmake.configureSettings": { > "CMAKE_EXPORT_COMPILE_COMMANDS": "ON" > } > > Yes, this change should be removed. > from the cmake_kit_new variable in ide_codium.py (because it is > redundant)? > > > For the kernel and the u-boot recipes that seams to be possible: > * > https://github.com/torvalds/linux/blob/master/scripts/clang-tools/gen_compile_commands.py > * > https://github.com/u-boot/u-boot/blob/master/scripts/gen_compile_commands.py > That looks like we can use these scripts which are available as make > targets out of the box. > > I know of them, but I didn't use them. > One advantage of these scripts is that they come with the kernel or u-boot. The bear tool is not yet part of oe-core. Before we could use it in ide-sdk it would have to be available as a bear-native recipe. Not sure this will be accepted by the core team. > I think you need to first have all the build files present in the project > and then the scripts parses those build files. > Probably this additional step can be automated in ide_codium.py. > But the build (I think .cmd) files aren't located in the > workspace/sources/ directory but in build/tmp/work/... > The ide-sdk tool calls bitbake to compile the modified recipe(s) (e.g. the kernel) and build the image which is needed for debugging. The cmd files should be always available. > In compile_commands.json all paths are absolute so this could be a problem. > No, this is fine. devtool ide-sdk generates these paths on the same machine. > I can play with the scripts and see if I can make them work. > One of the questions I have is: Are the scripts usable if we have clang available but compile the kernel with gcc? Yocto does not yet support compiling the kernel with clang, as far as I know. I guess this just works if the kernel is compiled with clang but not with gcc: https://github.com/torvalds/linux/blob/2e1b3cc9d7f790145a80cb705b168f05dab65df2/Makefile#L2007 I'm also not sure if there is a dependency somewhere in the Makefile which automatically initiates the build of the compile database or if the target needs to be called. If it needs to be called,I would try to extend the cml1.bbclass. Somehow like this (with more checks for clang), but I have no idea if this works: cml1_do_compile:append() { if [ -x ${S}/scripts <https://kernel.googlesource.com/pub/scm/linux/kernel/git/nmenon/linux/+/refs/tags/v5.1/scripts> /gen_compile_commands.py ] ; then oe_runmake compile_commands.json fi } Generating the compile database via bitbake would be needed to create the initial compile database when devtool ide-sdk or devtool build or bitbake is called to compile the kernel or the images. > > > But handling recipes with the ide-sdk fallback mode is not ideal. > Handling the recipes in a build-tool specific way leads to a much > better user experience. To add support for recipes using the kbuild > framework (u-boot, kernel) we could: > * Add another elif case for them to this > if: https://git.yoctoproject.org/poky/tree/scripts/lib/devtool/ide_s > dk.py#n377. > elif bb.data.inherits_class('cml1', recipe_d): > Then these recipes are no longer handled by the fallback mode of > ide-sdk > * Then we can recommend a Makefile vscode plugin > like > https://marketplace.visualstudio.com/items?itemName=ms-vscode.makefile-tools > or something more open source if you like. > Having a plugin like that allows to configure the plugin for cross- > compilation with Yocto's tool-chain. > Alternative we could generate some task which call make with the > right configuration. But this is usually a bit clunky as well. > > I don't fully understand the code to add kbuild and make build tool > specific handles in ide_sdk.py. > That is why I used the bear tool. > Well handling kbuild and using bear tool are two unrelated topics. > It can index all cases at the devtool ide-sdk stage. > User doesn't need to do anything additionally. > Yes, but with a different integration of either the scripts or bear-native. As I suggested above with the tweaks in e.g. the cml1.bbclass. > It would be better if kbuild and make were supported in ide_sdk.py. > kbuild (linux and u-boot) will be indexed by scripts, but how would make > projects be indexed (generation of compiler_commands.json) if bear tool > isn't used? > If the generation of the compile database is handled as a dependency in make, then it would just work (as it does also with cmake and meson) without any extra code. Otherwise it needs to be called also from VSCode. But probably not. > > Probably the usage of the bear tool isn't ideal, but it gives the > functionality that can later be optimized (replaced) with kbuild and make > handles in ide_sdk.py > I do not see this relation. Best regards, Adrian > I just don't get why in my implementation the do_package task breaks. > > Best regards, > Karlo >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#64226): https://lists.yoctoproject.org/g/yocto/message/64226 Mute This Topic: https://lists.yoctoproject.org/mt/109085158/21656 Mute #github:https://lists.yoctoproject.org/g/yocto/mutehashtag/github Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
