Hi Anusmita, Thanks for working on this, multiconfig support in devtool is long overdue (YOCTO #13933). Handling the mc: prefix when devtool calls bitbake is clearly needed. Before going further, I'd like to agree on the long term design of the workspace, as my series works on the same problem from another angle. https://git.openembedded.org/openembedded-core-contrib/log/?h=adrianf/ide-sdk-improvements
In most cases there is one recipe and one source tree, and what differs is only what that source is built for: another multiconfig, -native, nativesdk or a multilib variant such as lib32. Build output is already separate for all of them: each multiconfig has its own TMPDIR, and the BBCLASSEXTEND variants have their own WORKDIR. So the question is mostly how the workspace records which variants are modified, and which source tree they build. Your series puts the appends in a directory per multiconfig (appends/multiconfig/<mc>/) and selects them through BBFILES with BB_CURRENT_MC. This is small and makes it explicit which configuration is modified. The workspace is still keyed by the bare PN though, so a recipe can only be modified in one configuration at a time. This matches the current restriction to one BBCLASSEXTEND variant per recipe. My series keeps one bbappend per recipe file and scopes all settings with pn-<pn>, so that e.g. foo, foo-native and lib32-foo can be in the workspace at the same time. By default they share one source tree. A variant gets its own tree only if its SRC_URI, SRCREV or S differ, or if a variant builds in the source tree (B = S). The oe-workdir and oe-logs symlinks in the shared tree are named per variant, e.g. oe-workdir-native or oe-workdir-mc1. This does not cover BBMULTICONFIG yet: PN is the same in every configuration, so pn- cannot tell them apart, and something like a multiconfig specific override would be needed in the shared bbappend. The two approaches overlap but don't fit together well. With both merged, devtool would have one mechanism for multiconfigs (separate append files) and another one for BBCLASSEXTEND variants (scoped lines in a shared append). read_workspace, reset, update-recipe/finish and ide-sdk would have to handle both. Modifying e.g. foo-native and mc:mc1:foo at the same time would combine both mechanisms. So my question: what is the better long term design, also with -native, nativesdk and multilib in mind? Separate workspace appends per configuration or variant, or one append per recipe file with the modified variants scoped inside it and one shared source tree? Regards, Adrian
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#248629): https://lists.openembedded.org/g/openembedded-core/message/248629 Mute This Topic: https://lists.openembedded.org/mt/121897951/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
