While running the following command: "bitbake u-boot" or "UBOOT_MACHINE=omap3_beagle_config bitbake u-boot" .. getting the following error message: ERROR: Nothing PROVIDES 'u-boot' ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ERROR: u-boot was skipped: because UBOOT_MACHINE is not set ========================================== This is unclear for a newcomer due to the following reasons: 1) Not sure if UBOOT_MACHINE is supported or just the syntax is wrong somehow. 2) As it turns out "MACHINE=beagleboard bitbake u-boot" or similar kind should be passed, but I would have never guessed that as a newcomer. The suggestion is simply the addition or proper error diagnostics. Some reference should be taken to MACHINE rather than just UBOOT_MACHINE. That would clear up the situation right off-hand.
UBOOT_MACHINE can't be set externally because it's not in BB_ENV_EXTRAWHITE and it is not appropriate to add it there. It should be set to an appropriate value from your machine configuration file. Bottom line is you can't build u-boot for a machine that doesn't support it, and qemuarm doesn't. The recipe cannot tell which MACHINE will support it, only that UBOOT_MACHINE hasn't been set in the current configuration, which is exactly what it reports.
I'd say the best we could have is the error message to say "because UBOOT_MACHINE is not set, verify your machine configuration".
No no, you misunderstood the report! It should say: "MACHINE is not set" or something similar. The very least, it should say "UBOOT_MACHINE, nor MACHINE" or so. Please be supportive with users, not reluctant.
Giving errors about UBOOT_MACHINE, when the real issue is the MACHINE not specified is well... highly misleading to a user.
Also, "qemuarm" was not mentioned in the report at all, but beagleboard, so please stay more on topic and focus on the issue at hand.
MACHINE *is* specified; so it not being specified is not the problem. If it were not qemuarm then some other machine configuration where UBOOT_MACHINE hasn't been set. We'd take a patch to change it as Ross suggested.
Sorry, but you do not make any sense. There was *** NO *** any note about qemuarm, okay? There was not any. However, there was this mentioned because you are so attached to the outside world than this report, I have to repeat: "bitbake u-boot" or "UBOOT_MACHINE=omap3_beagle_config bitbake u-boot" I started with the first *** without *** MACHINE, okay?
MACHINE is set. It's set by default in your local.conf, so it doesn't matter whether you supply it on the command line or not.
Then, of course it should report that. "MACHINE=... blabla specified not supporting this". At any rate, the user experience is fully broken.
It should also mention that where it is specified exactly, so a file name for instance to make it explicitly clear as much as possible.
That would be more explicit than this: "because UBOOT_MACHINE is not set, verify your machine configuration" What does it mean machine configuration? UBOOT_MACHINE in the config? MACHINE in the config? UBOOT_MACHINE, MACHINE, or even something else on the command line? "machine configuration" is a vague term, so I do not support that suggestion. It should be as explicit as possible.
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-newmachine-conffile "Machine configuration" isn't a vague term, it's a specific file.
Except that it does not tell anything specific to a newcomer without a lot of investigation on the topic. Just be cool and provide error message for end users, not hard code developers. :) The whole point is machine in this case anyway, and its validity after all, not the whole machine configuration anyway.
To ensure we are not vague in the error message, we can say the following: ERROR: u-boot was skipped: because UBOOT_MACHINE is not set in the ${MACHINE} machine configuration file, please verify your configuration" Where ${MACHINE} will be the setting of MACHINE It's not easy to identify the location of where MACHINE might be set, but one can use bitbake -e <target> to determine that.
See previous comment
local.conf != command line.
As I said, it is not proper. When the machine does not support u-boot, it should just tell that up front by also mentioning the selected machine. UBOOT_MACHINE is a red herring in case of qemuarm.
Patch sent that implements what Saul said.
Then please open a bugreport for that. I am not asking that in this bugreport. Also, as written several times already, *please* post the links on bugzilla. Please be concerned about quality here, too.
Please do not change the status to review if it implements a different request; thank you for your understand. I appreciate your work, but if it is a different request, then it is a different request, and hence "review" would be incorrect.
Then I clearly don't understand your original request. Please explain clearly and concisely, in pseudocode if possible, exactly what it is that you are requesting and explain how my patch doesn't implement it. As far as I can understand the patch I've sent is the best that is possible, so marking as in review.
ok, you won the ping-pong game. As for the change ... you have not even bothered to paste a link even requested ...
I'm genuinely curious as to why my patch doesn't implement what you want, this wasn't some game for me. For looking up patches I recommend the patchworks service. http://patches.openembedded.org/patch/54893/.
Resolving fixed, the patch has been integrated into oe-core (beef66beaee926ec3d3640b79133fdb2ccc404f0) and no further improvements have been suggested.
Actually, I have had suggestions on the mailing list which seems to have been ignored. :/
One suggestion was along the lines of "I would like it to be more specific." There's a balance between concise and verbose, and listing the full path to all of the files that are involved in the machine configuration pushes too far into verbose for my liking. We state the machine name, so worst-case it's a find command to find the right initial configuration file. The other suggestion was along the lines of a warning when a variable is set in the environment. That's a valid use-case so we don't want to warn there.
1) Why would everyone ever use find and similar stuff when it can return the very only file at hand right away? I am not even sure what "all the files" you are referring to. 2) Do you seriously think it is a normal and intended situation if a user sets the machine to foo when it is already foo in the background? That seems pointless to me, and it is very likely that is not what the user wanted, i.e. we should warn.