set the PREFERRED_VERSION from command line
cover set the PREFERRED_VERSION from command line
The following changes since commit 2f792445bfc671081152f06e1cd507c049eb21ee:
logrotate: two minor fixes (2014-01-06 18:25:45 +0800)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/PV
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/PV
Robert Yang (1):
bitbake/cooker.py: set the PREFERRED_VERSION from command line
bitbake/lib/bb/cooker.py | 5 +++++ bitbake/lib/bb/cookerdata.py | 1 + scripts/oe-buildenv-internal | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-)
Signature · 1 line
1.8.3.1
RFC PATCH 1/1 bitbake/cooker.py: set the PREFERRED_VERSION from command line
We can't set the PREFERRED_VERSION from the command line, this will make it possible:
$ P_V="3.81" bitbake make $ P_V="3.81" bitbake make-native
Then the make-3.81 and make-native-3.81 will be built (the default is 3.82)
Another we that we have originally thought was:
$ export BB_PRESERVE_ENV=1 $ PREFERRED_VERSION_make = 3.81 bitbake make
This worked for make, but didn't work for make-native since we can't use "-" in a shell environment variable.
TODO:
* This is just a RFC and open for discussion, any comments is appreciated.
* It only can set the PREFERRED_VERSION for the pkg_to_build, we can make it more flexible, for example, if we found the keyword PREFERRED_VERSION in the P_V, we can set it for any recipe:
(assume core-image-sato RDEPENDS on make)
$ P_V="PREFERRED_VERSION_make=3.81" bitbake core-image-sato
* BTW, another questions, can we change the PREFERRED_VERSION to P_V or PF_V, and the PREFERRED_PROVIDER to P_P ot PF_P, please ? They are a little long to type and easy to make typos currently.
[YOCTO #4965]
--- bitbake/lib/bb/cooker.py | 5 +++++ bitbake/lib/bb/cookerdata.py | 1 + scripts/oe-buildenv-internal | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-)
bitbake/lib/bb/cooker.py +5 -0
@@ -180,6 +180,11 @@ class BBCooker: self.data = self.databuilder.data self.data_hash = self.databuilder.data_hash + P_V = self.data.getVar('P_V') + if P_V and len(self.configuration.pkgs_to_build) == 1: + pkg = ''.join(self.configuration.pkgs_to_build) + logger.info("Setting PREFERRED_VERSION_%s to %s" % (pkg, P_V)) + self.data.setVar("PREFERRED_VERSION_%s" % pkg, P_V) # # Special updated configuration we use for firing events #
bitbake/lib/bb/cookerdata.py +1 -0
@@ -128,6 +128,7 @@ class CookerConfiguration(object): self.dry_run = False self.tracking = False self.interface = [] + self.pkgs_to_build = [] self.env = {}
scripts/oe-buildenv-internal +1 -1
@@ -106,4 +106,4 @@ export BB_ENV_EXTRAWHITE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \ HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \ all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \ SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \ -SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR" +SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR P_V"
Signature · 1 line
1.8.3.1
Re: [RFC PATCH 1/1] bitbake/cooker.py: set the PREFERRED_VERSION from command line
Quoted 21 lines · Robert Yang
We can't set the
PREFERRED_VERSIONfrom the command line, this will make it possible:$ P_V="3.81" bitbake make $ P_V="3.81" bitbake make-nativeThen the make-3.81 and make-native-3.81 will be built (the default is 3.82)
Another we that we have originally thought was:
$ export BB_PRESERVE_ENV=1 $ PREFERRED_VERSION_make = 3.81 bitbake makeThis worked for make, but didn't work for make-native since we can't use "-" in a shell environment variable.
TODO:
* This is just a RFC and open for discussion, any comments is appreciated.
Quoted 5 lines
* It only can set the
PREFERRED_VERSIONfor thepkg_to_build, we can make it more flexible, for example, if we found the keywordPREFERRED_VERSIONin theP_V, we can set it for any recipe:
(assume core-image-sato RDEPENDS on make)$ P_V="PREFERRED_VERSION_make=3.81" bitbake core-image-sato
Well, this defines a different version of PREFERRED_VERSION with completely different semantics to the other one. I don't think this is acceptable or a good way to avoid this problem and will ultimately just confuse more users.
Quoted 3 lines
* BTW, another questions, can we change the
PREFERRED_VERSIONtoP_VorPF_V, and thePREFERRED_PROVIDERtoP_PotPF_P, please ? They are a little long to type and easy to make typos currently.
No, this would be extremely confusing with PV and other variables. Please use copy and paste or something ;-).
A better way of handling things might be to translate "__" to "-" when importing variables from the environment so you could set:
PREFERRED_VERSION_make__native = "3.81"
I'm open to other ideas but don't like P_V at all, particularly when it behaves differently to PREFERRED_VERSION.
Cheers,
Richard