13417 2019-06-20 20:43:25 +0000 Development manual coverage of devtool 2025-02-17 09:33:51 +0000 1 1 9 Documentation Development Manual development 0.0.0 x86 Multiple RESOLVED FIXED Medium+ normal 5.2 M4 1 bluelightning antonin.godard adrian.freihofer mark.morton michael.opdenacker randy.macleod srifenbark tim.orling --- --- Yes (doc changes required) oldest_to_newest 84297 0 bluelightning 2019-06-20 20:43:25 +0000 After the de-duplication work done for bug 9566 I am concerned that we require users who aren't using the SDK to go and look at the SDK manual, and given that these days usage of devtool outside of the SDK is likely the more common case this is somewhat unnatural. If we are to have it only in one place I would prefer it be the dev manual. Could we please move the generally applicable devtool documentation (starting from "2.4.1. Use devtool add to Add an Application" through to "2.7. Restoring the Target Device to its Original State") to the dev manual, and then add pointers from the SDK manual to the relevant new section(s) in the dev manual? 85500 1 srifenbark 2019-11-07 18:09:52 +0000 Paul, Yes - I will do this. Scott 87033 2 randy.macleod 2020-04-16 07:42:43 +0000 Paul can you work with Mark Morton on this? 100010 3 randy.macleod 2024-10-24 15:03:59 +0000 Bulk move of 5.1 M4 to 5.2 M2 as approved by AlexB. 100494 4 antonin.godard 2024-12-24 09:02:49 +0000 Hi, I've sent patches to address this: https://lists.yoctoproject.org/g/docs/topic/patch_0_2_move_devtool_doc/110269598 Feel free to review and comment the patches. Paul, compared to your initial plan, I've just left the "devtool ide-sdk" section in the Extensible SDK documentation. Antonin 100598 5 adrian.freihofer 2025-01-09 21:51:06 +0000 Hi Antonin, I think that devtool ide-sdk should be documented close to devtool modify or devtool deploy-target. It's just the most logical thing to do devtool modfiy and then devtool ide-sdk. Separating the sub-commands of devtool does not help from my point of view. The question is perhaps also a bit about what users understand as an SDK or an extensible SDK. Is it one of the old eSDK installers or the newer ability to switch to different application developer workflows from any bitbake environment? I can tell you that devtool ide-sdk has been developed with only the new bitbake environment based setup in mind. There is no technical argument why it should not work from an eSDK installer environment. But I did not even test that once. One of my main motivations for developing devtool ide-sdk was to get something which works without a populate_sdk(_ext) step. So it is definitely not more related to the eSDK in the sense of the old installer then all other features of devtool. Therefore I think it would be better to move also the devtool ide-sdk section. 100601 6 antonin.godard 2025-01-10 08:46:35 +0000 (In reply to Adrian from comment #5) > Hi Antonin, > > I think that devtool ide-sdk should be documented close to devtool modify or > devtool deploy-target. It's just the most logical thing to do devtool modfiy > and then devtool ide-sdk. Separating the sub-commands of devtool does not > help from my point of view. > > The question is perhaps also a bit about what users understand as an SDK or > an extensible SDK. Is it one of the old eSDK installers or the newer ability > to switch to different application developer workflows from any bitbake > environment? > > I can tell you that devtool ide-sdk has been developed with only the new > bitbake environment based setup in mind. There is no technical argument why > it should not work from an eSDK installer environment. But I did not even > test that once. One of my main motivations for developing devtool ide-sdk > was to get something which works without a populate_sdk(_ext) step. So it is > definitely not more related to the eSDK in the sense of the old installer > then all other features of devtool. > > Therefore I think it would be better to move also the devtool ide-sdk > section. Hi Adrian, I had never used ide-sdk before, so thanks for your input on this. I might have been mislead by the current title for the section "Configuring IDEs for the extensible SDK with ``devtool ide-sdk``". In the following paragraphs the ide-sdk functionality is used in the context of an eSDK. So if I were to move this, I would also need to rephrase some paragraphs to make it independent from the eSDK. Since I don't have experience with the eSDK, I can try rephrasing in a new version of my series, but would appreciate your review. Even better if you got some time I would also take a patch from you for this. Antonin 100603 7 adrian.freihofer 2025-01-10 13:05:14 +0000 Sure, I can do the rephrasing of the devtool ide-sdk section. But still the question for me is, what's the correct wording then? This section https://docs.yoctoproject.org/sdk-manual/extensible.html#two-ways-to-install-the-extensible-sdk kind of introduces a wording like "extensible SDK" = "Yocto cross-toolchain, sysroots and related tools". It does not matter if the SDK is bootstrapped directly from the bitbake environment (e.g. by calling devtool ide-sdk) or via populate_sdk_ext and installing the installer. That's the wording which I used for the current devtool ide-sdk section. Before this section was added to the manual the wording was probably more like "Extensible SDK" = "The eSDK-installer". To avoid such kind of confusion I can try to update https://docs.yoctoproject.org/sdk-manual/extensible.html#devtool-ide-sdk-configures-ides-for-the-extensible-sdk like this: - Replace the term "extensible SDK" by "SDK" - Change with an initial paragraph to something like this: 2.4.3 devtool ide-sdk configures IDEs for the SDKs devtool ide-sdk automatically configures IDEs to use the SDK. To ensure that all the parts that make up the SDK (cross-toolchain, sysroots, native tools and more) are available, devtool ide-sdk assembles the SDK with the help of bitbake before it generates the IDE configuration. The Yocto SDKs basically support two different development modes. devtool ide-sdk supports both of them: ... By the way, this discussion reminds my that I should probably send a patch which actively disables the devtool ide-sdk plugin if devtool runs from an installer based setup (context.fixed_setup is True). At least the shared mode will not work without a few extra lines of code and also the modified mode is not tested. I will probably actively remove the support for the eSDK installer and also mention this in the documentation. 101107 8 antonin.godard 2025-02-17 09:33:51 +0000 Hi, This was done with commit https://git.yoctoproject.org/yocto-docs/commit/?id=044d3185b858fce1febcfe3a6834b883f9a598fa. Moving to Resolved fixed. Antonin