Closed RomainNaour closed 3 years ago
I like your first idea keepgoing
. Should be integrated.
For the second one I'm not sure whether it is a good idea to have such specific bitbake-command built-in in cooker.
Have you seen my foreach
-idea (#62). foreach'ing over sources (or builds) and executing arbitrary commands could be sufficient for this problem.
(My understanding is that --runall=fetch
is just one of hundreds (if not thousands) of possible commands)
In any case, please do 2 PRs, one for each feature.
I'm ok about the --keepgoing
option. It's easy to implement and may be useful. But it's not-so-easy to test. Maybe mocking bitbake
and ensuring that the -k
option is present?
I'm also positive about the source
command. I find it easier to use and to remember than foreach
.
Could you do two different pull requests for this two features?
Hello, Sure, I'll do a PR for each feature. I wanted to share my WIP branch to get feedback :) Ok for the keepgoing option, I'll keep as is and I'll try to add a test for it. For the source command (I think this is a must), it's inspired by the Buildroot "make source" that is a very intuitive command than the Yocto "--runall=fetch". I don't think we need to support other possibilities.
I confirm that Buildroot make source
is really useful when you prepare a training session that will take place in a training room with a rather slow Internet connection and a dozen of attendees.
the make source
command and bitbake runall=fetch
make the project download all sources or all concerned recipes of the specified build(s)?
bitbake --runall=fetch <recipe>
so you need to give a recipe and it will download all sources needed to build this recipe. It's immensly usefull in a large number of cases... TBH I don't think I ever used runall with anything else but fetch.Indeed, the idea is not to create a download mirror but only fetch all sources needed to build offline each configuration described in the json file. The idea is very close to the Buildroot "make source". The amount of downloaded archives depends on the selected packages.
OK, I understand the utility of integrating the command to cooker. However, I'm still not a friend of creating special first-order cooker command for it. Especially when there is already a source
-entity in cooker which is not the source of a recipe.
It seems to me that an option to the build
-sub-command would be more appropriate. As there is the option to build the sdk (-s
) of a build - which is also influencing the bitbake-invocation (by adding deploy_sdk
): cooker build -s [<build-name0> [build-name1...]]
today builds the sdk related to the build-name (the corresponding image-recipe).
Why not: cooker build -d [<build-name0> [build-name1...]]
to issue the runall=fetch
bitbake option on the selected builds (if empty all of them would be handled: cooker build -d
) Like sudo apt install -d
for only downloading deb-files.
(This comment was very small in the beginning and I could not stop adding content and reasoning to it.)
Using "cooker source" allow to fetch all sources for a config file without dealing with builds names. Since "cooker build -d" seems to do the same, I'm fine with your proposal. Thanks!
Hello,
Introduce a new 'source' command to do a "bitbake --runall=fetch core-image-base" to prepare offline-builds. Add a 'keepgoing' option to build command to continue the first build even if one of the recipe failed.
Best regards, Romain