* [PATCH V3 0/2] populate_sdk_ext: two fixes @ 2015-05-12 6:19 Chen Qi 2015-05-12 6:19 ` [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi 2015-05-12 6:19 ` [PATCH V3 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi 0 siblings, 2 replies; 9+ messages in thread From: Chen Qi @ 2015-05-12 6:19 UTC (permalink / raw) To: openembedded-core The following changes since commit 7ffe10df73cc20d10fcd41b121074445273bd60e: license_class: license_create_manifest improvment (2015-05-09 22:26:02 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/populate_sdk_ext_2_fixes http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/populate_sdk_ext_2_fixes Chen Qi (2): populate_sdk_ext: install the latest buildtools-tarball populate_sdk_ext: consider custom configuration in local.conf meta/classes/populate_sdk_ext.bbclass | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-12 6:19 [PATCH V3 0/2] populate_sdk_ext: two fixes Chen Qi @ 2015-05-12 6:19 ` Chen Qi 2015-05-12 16:19 ` Khem Raj 2015-05-12 6:19 ` [PATCH V3 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi 1 sibling, 1 reply; 9+ messages in thread From: Chen Qi @ 2015-05-12 6:19 UTC (permalink / raw) To: openembedded-core If we do `bitbake buildtools-tarball' and then after one day do `bitbake core-image-minimal -c populate_sdk_ext', we would meet errors like below. | install: cannot stat '/buildarea2/chenqi/poky/build-systemd/tmp/deploy/sdk/ poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-standalone -1.8+snapshot-20150429.sh': No such file or directory The problem is that the output name for buildtools-tarball has ${DATE} in it. So if populate_sdk_ext task is executed but buildtools-tarball is not rebuilt, the above error appears. Instead of hardcoding ${DISTRO_VERSION} which consists of ${DATE} in the install_tools() function, we should find the latest buildtools-tarball based on the modification time and install it. [YOCTO #7674] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> --- meta/classes/populate_sdk_ext.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index dc2c58e..2fc4c11 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -168,7 +168,9 @@ install_tools() { ln -sr ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath}/recipetool ${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/recipetool touch ${SDK_OUTPUT}/${SDKPATH}/.devtoolbase - install ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh ${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and install it + buildtools_path=`ls -t1 ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` + install $buildtools_path ${SDK_OUTPUT}/${SDKPATH} install ${SDK_DEPLOY}/${BUILD_ARCH}-nativesdk-libc.tar.bz2 ${SDK_OUTPUT}/${SDKPATH} } -- 1.9.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-12 6:19 ` [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi @ 2015-05-12 16:19 ` Khem Raj 2015-05-13 1:45 ` ChenQi 0 siblings, 1 reply; 9+ messages in thread From: Khem Raj @ 2015-05-12 16:19 UTC (permalink / raw) To: Chen Qi; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 583 bytes --] > On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote: > > - install ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh ${SDK_OUTPUT}/${SDKPATH} > + # find latest buildtools-tarball and install it > + buildtools_path=`ls -t1 ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` > + install $buildtools_path ${SDK_OUTPUT}/${SDKPATH} > why not create a symink instead of poking using wild chars [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-12 16:19 ` Khem Raj @ 2015-05-13 1:45 ` ChenQi 2015-05-13 1:56 ` Khem Raj 0 siblings, 1 reply; 9+ messages in thread From: ChenQi @ 2015-05-13 1:45 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On 05/13/2015 12:19 AM, Khem Raj wrote: >> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote: >> >> - install ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh ${SDK_OUTPUT}/${SDKPATH} >> + # find latest buildtools-tarball and install it >> + buildtools_path=`ls -t1 ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` >> + install $buildtools_path ${SDK_OUTPUT}/${SDKPATH} >> > why not create a symink instead of poking using wild chars Because it's simpler. //Chen Qi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-13 1:45 ` ChenQi @ 2015-05-13 1:56 ` Khem Raj 2015-05-13 2:27 ` ChenQi 0 siblings, 1 reply; 9+ messages in thread From: Khem Raj @ 2015-05-13 1:56 UTC (permalink / raw) To: ChenQi; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 813 bytes --] > On May 12, 2015, at 6:45 PM, ChenQi <Qi.Chen@windriver.com> wrote: > > On 05/13/2015 12:19 AM, Khem Raj wrote: >>> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote: >>> >>> - install ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh ${SDK_OUTPUT}/${SDKPATH} >>> + # find latest buildtools-tarball and install it >>> + buildtools_path=`ls -t1 ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` >>> + install $buildtools_path ${SDK_OUTPUT}/${SDKPATH} >>> >> why not create a symink instead of poking using wild chars > > Because it's simpler. what happens if I touch an older installer ? > > //Chen Qi [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-13 1:56 ` Khem Raj @ 2015-05-13 2:27 ` ChenQi 2015-05-13 11:03 ` Paul Eggleton 0 siblings, 1 reply; 9+ messages in thread From: ChenQi @ 2015-05-13 2:27 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On 05/13/2015 09:56 AM, Khem Raj wrote: >> On May 12, 2015, at 6:45 PM, ChenQi <Qi.Chen@windriver.com> wrote: >> >> On 05/13/2015 12:19 AM, Khem Raj wrote: >>>> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote: >>>> >>>> - install ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh ${SDK_OUTPUT}/${SDKPATH} >>>> + # find latest buildtools-tarball and install it >>>> + buildtools_path=`ls -t1 ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` >>>> + install $buildtools_path ${SDK_OUTPUT}/${SDKPATH} >>>> >>> why not create a symink instead of poking using wild chars >> Because it's simpler. > what happens if I touch an older installer ? Hi Khem, I make this patch to avoid installing a non-existent buildools-tarball. If we touch an old buildtools-tarball, the installation would still succeed. The touched one is installed. What would lead to a potential problem is the following situation. The user built buildtools-tarball, after one day, he modified key part of buildtools-tarball recipe, rebuilt it, and then he deliberately touched the old one, and then he built an ext SDK. I don't think that's a situation we need to take care of. But if you insist that we should, you can suggest a reasonable symlink name and I would make a new patch. Best Regards, Chen Qi > >> //Chen Qi ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-13 2:27 ` ChenQi @ 2015-05-13 11:03 ` Paul Eggleton 2015-05-13 15:59 ` Khem Raj 0 siblings, 1 reply; 9+ messages in thread From: Paul Eggleton @ 2015-05-13 11:03 UTC (permalink / raw) To: openembedded-core, ChenQi On Wednesday 13 May 2015 10:27:34 ChenQi wrote: > On 05/13/2015 09:56 AM, Khem Raj wrote: > >> On May 12, 2015, at 6:45 PM, ChenQi <Qi.Chen@windriver.com> wrote: > >> > >> On 05/13/2015 12:19 AM, Khem Raj wrote: > >>>> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote: > >>>> > >>>> - install > >>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN > >>>> E_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh > >>>> ${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and > >>>> install it > >>>> + buildtools_path=`ls -t1 > >>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN > >>>> E_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` + install > >>>> $buildtools_path ${SDK_OUTPUT}/${SDKPATH} > >>> > >>> why not create a symink instead of poking using wild chars > >> > >> Because it's simpler. > > > > what happens if I touch an older installer ? > > Hi Khem, > > I make this patch to avoid installing a non-existent buildools-tarball. > If we touch an old buildtools-tarball, the installation would still > succeed. The touched one is installed. > What would lead to a potential problem is the following situation. > The user built buildtools-tarball, after one day, he modified key part > of buildtools-tarball recipe, rebuilt it, and then he deliberately > touched the old one, and then he built an ext SDK. > I don't think that's a situation we need to take care of. > But if you insist that we should, you can suggest a reasonable symlink > name and I would make a new patch. Honestly I don't see this is as being a problem we need to handle - who is going to touch this file during normal usage? Builds failing under the conditions described is a much more pressing issue at this point. It could be that we should re-visit whether using buildtools-tarball rather than having its contents be part of the native portion of the SDK is the right approach. I'm not sure that we need to do that just at this moment though. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball 2015-05-13 11:03 ` Paul Eggleton @ 2015-05-13 15:59 ` Khem Raj 0 siblings, 0 replies; 9+ messages in thread From: Khem Raj @ 2015-05-13 15:59 UTC (permalink / raw) To: Paul Eggleton; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 2546 bytes --] > On May 13, 2015, at 4:03 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote: > > On Wednesday 13 May 2015 10:27:34 ChenQi wrote: >> On 05/13/2015 09:56 AM, Khem Raj wrote: >>>> On May 12, 2015, at 6:45 PM, ChenQi <Qi.Chen@windriver.com> wrote: >>>> >>>> On 05/13/2015 12:19 AM, Khem Raj wrote: >>>>>> On May 11, 2015, at 11:19 PM, Chen Qi <Qi.Chen@windriver.com> wrote: >>>>>> >>>>>> - install >>>>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN >>>>>> E_PKGARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh >>>>>> ${SDK_OUTPUT}/${SDKPATH} + # find latest buildtools-tarball and >>>>>> install it >>>>>> + buildtools_path=`ls -t1 >>>>>> ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUN >>>>>> E_PKGARCH}-buildtools-nativesdk-standalone-*.sh | head -n1` + > install >>>>>> $buildtools_path ${SDK_OUTPUT}/${SDKPATH} >>>>> >>>>> why not create a symink instead of poking using wild chars >>>> >>>> Because it's simpler. >>> >>> what happens if I touch an older installer ? >> >> Hi Khem, >> >> I make this patch to avoid installing a non-existent buildools-tarball. >> If we touch an old buildtools-tarball, the installation would still >> succeed. The touched one is installed. >> What would lead to a potential problem is the following situation. >> The user built buildtools-tarball, after one day, he modified key part >> of buildtools-tarball recipe, rebuilt it, and then he deliberately >> touched the old one, and then he built an ext SDK. >> I don't think that's a situation we need to take care of. >> But if you insist that we should, you can suggest a reasonable symlink >> name and I would make a new patch. > > Honestly I don't see this is as being a problem we need to handle - who is > going to touch this file during normal usage? Builds failing under the > conditions described is a much more pressing issue at this point. > It has caused issues when we used such an approach for other artifacts and debugging it was hard since we lost trackability with wildcads I was just sharing the experience. Ofcource the issue at hand is always pressing thats why we are fixing it. > It could be that we should re-visit whether using buildtools-tarball rather > than having its contents be part of the native portion of the SDK is the right > approach. I'm not sure that we need to do that just at this moment though. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH V3 2/2] populate_sdk_ext: consider custom configuration in local.conf 2015-05-12 6:19 [PATCH V3 0/2] populate_sdk_ext: two fixes Chen Qi 2015-05-12 6:19 ` [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi @ 2015-05-12 6:19 ` Chen Qi 1 sibling, 0 replies; 9+ messages in thread From: Chen Qi @ 2015-05-12 6:19 UTC (permalink / raw) To: openembedded-core Copy the contents of local.conf under TOPDIR into the final generated local.conf. In this way, custom settings are also made into the final local.conf like IMAGE_INSTALL, DISTRO_FEATURES, VIRTUAL-RUNTIME_xxx, etc. Before this change, installing extensible SDK would usually report failure when preparing the build system if the user has custom configuration for DISTRO_FEATURES in local.conf. Also, items in IMAGE_INSTALL_append in local.conf also don't get built correctly. This patch solves the above problem. A blacklist mechanism is also introduced so that we can blacklist variables that should not be copied into the final local.conf file. Currently, the blacklist contains 'TMPDIR', 'SSTATE_DIR', 'DL_DIR', 'STAMPS_DIR', 'BASE_WORKDIR' and 'DEPLOY_DIR'. What these variables have in common is that they are set in bitbake.conf using '?=' or '??='. In addition, we check to avoid any setting that might lead to host path bleeding into SDK's configuration. [YOCTO #7616] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> --- meta/classes/populate_sdk_ext.bbclass | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index 2fc4c11..49ba26b 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -16,6 +16,7 @@ SDK_RDEPENDS_append_task-populate-sdk-ext = " ${SDK_TARGETS}" SDK_RELOCATE_AFTER_INSTALL_task-populate-sdk-ext = "0" SDK_META_CONF_WHITELIST ?= "MACHINE DISTRO PACKAGE_CLASSES" +SDK_META_CONF_BLACKLIST ?= "TMPDIR DL_DIR SSTATE_DIR STAMPS_DIR BASE_WORKDIR DEPLOY_DIR" SDK_TARGETS ?= "${PN}" OE_INIT_ENV_SCRIPT ?= "oe-init-build-env" @@ -114,6 +115,28 @@ python copy_buildsystem () { f.write('# this configuration provides, it is strongly suggested that you set\n') f.write('# up a proper instance of the full build system and use that instead.\n\n') + # Copy configurations from the current local.conf + builddir = d.getVar('TOPDIR', True) + with open(builddir + '/conf/local.conf', 'r') as lf: + varblacklist = d.getVar('SDK_META_CONF_BLACKLIST', True).split() + skip = False + for line in lf: + line = line.lstrip() + if line.startswith('#'): + continue + # avoid host path bleeding into SDK configuration + if line.find('"/') != -1: + continue + for varname in varblacklist: + if line.startswith(varname): + skip = True + break + if not skip: + f.write(line) + skip = False + f.write('\n') + + # Configurations in local.conf which are specific for extensible SDK f.write('INHERIT += "%s"\n\n' % 'uninative') f.write('CONF_VERSION = "%s"\n\n' % d.getVar('CONF_VERSION')) -- 1.9.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-05-13 15:59 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-05-12 6:19 [PATCH V3 0/2] populate_sdk_ext: two fixes Chen Qi 2015-05-12 6:19 ` [PATCH V3 1/2] populate_sdk_ext: install the latest buildtools-tarball Chen Qi 2015-05-12 16:19 ` Khem Raj 2015-05-13 1:45 ` ChenQi 2015-05-13 1:56 ` Khem Raj 2015-05-13 2:27 ` ChenQi 2015-05-13 11:03 ` Paul Eggleton 2015-05-13 15:59 ` Khem Raj 2015-05-12 6:19 ` [PATCH V3 2/2] populate_sdk_ext: consider custom configuration in local.conf Chen Qi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.