On Wednesday 10 December 2014 17:51:16 Paul Eggleton wrote: > On Tuesday 09 December 2014 13:58:02 Trevor Woerner wrote: > > On 12/09/14 11:08, Paul Eggleton wrote: > > > "devtool build" isn't strictly required in this phase, I added it > > > primarily to support future usage in the SDK where the intention is to > > > do everything through the devtool command, although that is a usage > > > model that isn't enabled yet. However, it is a convenient shortcut for > > > "bitbake -c install <recipename>" (which is all you need to do for > > > "devtool deploy" to be able to work.) > > > > True, we did talk about this before. All I'm saying is that the colour > > feature of bitbake is really nice, useful, and helpful (to visually > > parse output) and if we've lost colour because we've wrapped bitbake > > with "devtool build" then we're taking a step backwards. > > > > But I'll concede the point if the future usage in the SDK turns out to > > be really helpful. All I'm saying at this point is I have no idea what > > this future usage might be or what your ideas are for this step, and for > > the time-being (i.e. without knowing or working with this SDK usage) > > "devtool build" is a step backwards from "bitbake". > > OK, understood. I'll have a think about it.
I've fixed this on the branch; turns out there is an easy way to fool processes into thinking they are connected to a real terminal and thus have bitbake use the normal colour and terminal handling. > > > "devtool deploy" is not related to do_deploy - it places files for the > > > recipe on a nominated target machine without having to worry about > > > packaging; we have no other equivalent for this at the moment. Perhaps > > > it > > > could have a different name in case the naming overlap is confusing. > > > > Ah yes, sorry I forgot... maybe something more explicit like > > "deploy_to_target"? ;-) > > push_to_target? > > upload_to_target? > > Hmm, perhaps deploy-target would be more in line with the git-style command > naming I've been using. Fixed on the branch. > > LICENSE > > If the tool that creates the recipe can't find any explicit licensing > > information, it leaves LICENCE blank. Would it be better, if there's no > > explicit license, to set it to "CLOSED"? Otherwise the first build will > > fail and the user will have to figure out what to do in order to get the > > recipe to build. > > Possibly yes. Ideally people would take an interest in setting this > properly, but I do recognise that it's not a high priority when you are > just getting started. What might be missing is some kind of modal operation > where during initial development you aren't bothered by all of these recipe > quality checks, but then when it comes to production the checks are > re-enabled. I've made this change on the branch (with an appropriate warning comment preceding it). > > code updates > > Maybe my inexperience with externalsrc is showing through here (I've > > never used it before), but as I play with this new feature, I'm testing > > it by trying to include a very old project I wrote years ago. As luck > > would have it, that project needs updates (it doesn't quite work as-is > > in qemux86/core-image-x11). So here I am going through the cycle of > > working on its source, and building new images. What I've noticed is > > when I create the image I keep getting the same old sources used over > > and over from when I first added this project "devtool add" (and it > > doesn't matter whether I use bitbake or devtool to build it, it even > > keeps using the old sources even when I perform commits in the sources > > and even when I perform a "bitbake -c cleansstate <recipe>"!). The only > > way I can move forward is to "devtool reset" and then "devtool add". > > > > In my scenario I have a base image I have already built > > (core-image-x11). Now I want to add one package to that image from > > sources found on my local machine. I also want to go through the cycle > > of editing those sources, building a new image, and runqemu'ing the new > > image to test my changes. I can't seem to do that without knowing > > devtool and/or bitbake magic. I either have to "devtool reset" or I have > > to "bitbake -c clean core-image-x11" because just modifying the sources > > doesn't cause the image to be regenerated. > > It's not supposed to behave this way, although I have reproduced it here - I > think I hadn't actually tested rebuilding an image with a recipe in the > workspace added to the image. The problem is that the do_compile task is > being marked as nostamp, but the way bitbake behaves now, that doesn't > cause any dependent task signatures to be changed and thus no dependent > tasks get run afterwards. Either I'll have to change that or work out a > different way of ensuring do_compile and dependent tasks get run - either > way, you should only have to run a build that calls for the recipe (be it > the recipe itself or something that depends upon it), no cleaning/resetting > should be needed. I'll try to fix this tomorrow. OK, I've fixed this on the branch as well. You should now find that rebuilding the image always triggers a compile -> install -> package etc. of the recipe(s) in the workspace first. (It'll end up triggering other recipes to rebuild as well if they are in the chain; we may have to address that differently later for cases where that's annoying). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
