It would be nice to have this feature for experimenting, at least, around. u-boot is getting several versions, and it would be simpler to test a different version in case of tracking buys and so forth rather than modifying the config file, and then modifying it back. If one uses the -b option for absolute path to the recipe, then it will not handle the dependencies automatically. If it is already possible, then document it, please.
Thanks for the report. One can use the PREFERRED_VERSION_u-boot = "<version>" in your local.conf file, I believe the variable is documented in the manual. We use this method for the compiler and eglibc, and they are set in the distro/include/tcmode-default.inc or distro/include/default-versions. So examples exist. Is that information sufficient?
local.conf != command line.
(In reply to comment #0) > It would be nice to have this feature for experimenting, at least, around. > > u-boot is getting several versions, and it would be simpler to test a > different version in case of tracking buys and so forth rather than > modifying the config file, and then modifying it back. > > If one uses the -b option for absolute path to the recipe, then it will not > handle the dependencies automatically. > I think that you can use "bitbake uboot-<version>" . > If it is already possible, then document it, please.
(In reply to comment #3) > (In reply to comment #0) > > It would be nice to have this feature for experimenting, at least, around. > > > > u-boot is getting several versions, and it would be simpler to test a > > different version in case of tracking buys and so forth rather than > > modifying the config file, and then modifying it back. > > > > If one uses the -b option for absolute path to the recipe, then it will not > > handle the dependencies automatically. > > > > I think that you can use "bitbake uboot-<version>" . > Now, we can't use the bitbake uboot-<version>, but you can set BB_PRESERVE_ENV=1 and then set PREFERRED_VERSION_xxx from the environment. There is one other problem, you can't use "-" in a shell environment variable so you can't do: PREFERRED_VERSION_make-native = xxx which is annoying. We might want to add some kind of mangling mechanism like a double underscore translating to a dash or something... Cheers, Richard We will go on working on it in 1.6 > > If it is already possible, then document it, please.
I don't think this is worth doing, particularly given the complexities of invalid chars in the environment variable names. No action in a long time so closing.