Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, 6 Dec 2012, Chris Larson wrote: > On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day > wrote: > ok, that's just silly (but that could be the 9% quebec beer > talking). if i'm working with just one layer, then this: > > FILESEXTRAPATHS_prepend := "rday" > > works fine: > > > FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:... > > if that fails with more than one layer, then that is, quite simply, > asinine. > > > I really don't see why you're failing to grasp such a basic concept > as a colon separated variable. Do you think you can add something to > PATH without adding a colon? arrr ... i'll try this again. as i read it (and i'm willing to be corrected), the value of FILESEXTRAPATHS_prepend is not used for a simple, textual prepend. period. end of discussion. rather, it is used as the basis for extending FILESPATH based on *processing* that involves taking the value of OVERRIDES into consideration. using the example i was talking about yesterday (the meta-ti layer and the netbase recipe), if my netbase .bbappend contains *only* this: FILESEXTRAPATHS_prepend := "/rday" then if i use bitbake-env to see what happens with FILESPATH wrt to that recipe, i see (replacing ":" with newlines for prettiness): $ bitbake-env -r netbase FILESPATH | tr : '\n' Parsing recipes..done. # FILESPATH="${@base_set_filespath(["${FILE_DIRNAME}/${BP}", "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" FILESPATH="/rday/linux-gnueabi /rday/arm /rday/build-linux /rday/pn-netbase /rday/dm814x-evm /rday/ti814x /rday/armv7a /rday/ /rday/class-target /rday/forcevariable /rday/libc-glibc /rday/ /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase ... snip ... see? how much clearer can i make this? if you prefer adding the silly colon to that line, as in: FILESEXTRAPATHS_prepend := "/rday:" it ends up making exactly *no* difference. none. zip. squat. you're quite welcome to add as many as you like: FILESEXTRAPATHS_prepend := "/rday:" and it will make no difference since, as i read it, you are not specifying a value to be literally prepended to FILESPATH, you are identifying a *directory* to be processed (by, i believe, def base_set_filespath(path, d) in utils.bbclass). if for some bizarre reason you like to add that superfluous ":", knock yourself out, but don't claim that it is somehow *necessary* because of a colon-separated list of directories. on the other hand, it *is* useful if you want to add, say, *two* dirtectories, as in: FILESEXTRAPATHS_prepend := "/rday1:/rday2" which will produce (predictably): FILESPATH="/rday1/linux-gnueabi /rday1/arm /rday1/build-linux /rday1/pn-netbase /rday1/dm814x-evm /rday1/ti814x /rday1/armv7a /rday1/ /rday1/class-target /rday1/forcevariable /rday1/libc-glibc /rday1/ /rday2/linux-gnueabi /rday2/arm /rday2/build-linux /rday2/pn-netbase /rday2/dm814x-evm /rday2/ti814x /rday2/armv7a /rday2/ /rday2/class-target /rday2/forcevariable /rday2/libc-glibc /rday2/ /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase ... snip ... so why am i so fixated on this? thanks for asking. i find the current, widespread usage of this form (with the colon): FILESEXTRAPATHS_prepend := "${THISDIR}/patches:" potentially misleading since people reading the .bbappend file will (quite naturally) assume that, hey, that must represent a literal prepend since it includes the colon. and they will be wrong. in fact, i'm willing to bet that, based on that ubiquitous usage, many people who wrote .bbappend files had no idea that that's what was happening. i'm willing to bet that, in many cases, those people just added what they thought was a simple overriding directory name, having no clue that that was being expanded into multiple directories, one of which just *happened* to match the directory name they supplied. so things worked out, but not for the reason they thought. as it stands, the way things are done now will work just fine, of course. but i think it's visually misleading, and not very well explained. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn:
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Friday 07 December 2012 08:04:58 Robert P. J. Day wrote: > On Thu, 6 Dec 2012, Chris Larson wrote: > > On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day wrote: > > ok, that's just silly (but that could be the 9% quebec beer > > talking). if i'm working with just one layer, then this: > > > > FILESEXTRAPATHS_prepend := "rday" > > > > works fine: > > > > FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netb > > ase:... > > > > if that fails with more than one layer, then that is, quite simply, > > asinine. > > > > I really don't see why you're failing to grasp such a basic concept > > as a colon separated variable. Do you think you can add something to > > PATH without adding a colon? > > arrr ... i'll try this again. as i read it (and i'm > willing to be corrected), the value of FILESEXTRAPATHS_prepend is not > used for a simple, textual prepend. period. end of discussion. > > rather, it is used as the basis for extending FILESPATH based on > *processing* that involves taking the value of OVERRIDES into > consideration. using the example i was talking about yesterday (the > meta-ti layer and the netbase recipe), if my netbase .bbappend > contains *only* this: > > FILESEXTRAPATHS_prepend := "/rday" > > then if i use bitbake-env to see what happens with FILESPATH wrt to > that recipe, i see (replacing ":" with newlines for prettiness): > > $ bitbake-env -r netbase FILESPATH | tr : '\n' > Parsing recipes..done. > # FILESPATH="${@base_set_filespath(["${FILE_DIRNAME}/${BP}", > "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" > FILESPATH="/rday/linux-gnueabi > /rday/arm > /rday/build-linux > /rday/pn-netbase > /rday/dm814x-evm > /rday/ti814x > /rday/armv7a > /rday/ > /rday/class-target > /rday/forcevariable > /rday/libc-glibc > /rday/ > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/li > nux-gnueabi > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/a > rm > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/b > uild-linux > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/p > n-netbase ... snip ... > > see? how much clearer can i make this? if you prefer adding the > silly colon to that line, as in: > > FILESEXTRAPATHS_prepend := "/rday:" > > it ends up making exactly *no* difference. none. zip. squat. > you're quite welcome to add as many as you like: > > FILESEXTRAPATHS_prepend := "/rday:" > > and it will make no difference since, as i read it, you are not > specifying a value to be literally prepended to FILESPATH, you are > identifying a *directory* to be processed (by, i believe, def > base_set_filespath(path, d) in utils.bbclass). if for some bizarre > reason you like to add that superfluous ":", knock yourself out, but > don't claim that it is somehow *necessary* because of a > colon-separated list of directories. > > on the other hand, it *is* useful if you want to add, say, *two* > dirtectories, as in: > > FILESEXTRAPATHS_prepend := "/rday1:/rday2" Right, and this is what you'll get if two layers bbappend the same recipe and both prepend to FILESEXTRAPATHS, which is not an unlikely situation. If you want that to work correctly then you *must* include the trailing colon. The easiest thing is to just include it every time you prepend to FILESEXTRAPATHS. > which will produce (predictably): > > FILESPATH="/rday1/linux-gnueabi > /rday1/arm > /rday1/build-linux > /rday1/pn-netbase > /rday1/dm814x-evm > /rday1/ti814x > /rday1/armv7a > /rday1/ > /rday1/class-target > /rday1/forcevariable > /rday1/libc-glibc > /rday1/ > /rday2/linux-gnueabi > /rday2/arm > /rday2/build-linux > /rday2/pn-netbase > /rday2/dm814x-evm > /rday2/ti814x > /rday2/armv7a > /rday2/ > /rday2/class-target > /rday2/forcevariable > /rday2/libc-glibc > /rday2/ > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/li > nux-gnueabi > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/a > rm > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/b > uild-linux > /home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/p > n-netbase ... snip ... > > so why am i so fixated on this? thanks for asking. > > i find the current, widespread usage of this form (with the colon): > > FILESEXTRAPATHS_prepend := "${THISDIR}/patches:" > > potentially misleading since people reading the .bbappend file will > (quite naturally) assume that, hey, that must represent a literal > prepend since it includes the colon. It *is* a literal prepend - to FILESEXTRAPATHS. In your discussion above you are conflating FILESPATH with FILESEXTRAPATHS. The former is constructed based on the latter in conjuction with OVERRIDES; they are not the same variable. > i'm willing to bet that, in many cases, those people just ad
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Fri, 7 Dec 2012, Paul Eggleton wrote: > On Friday 07 December 2012 08:04:58 Robert P. J. Day wrote: > > > > i find the current, widespread usage of this form (with the colon): > > > > FILESEXTRAPATHS_prepend := "${THISDIR}/patches:" > > > > potentially misleading since people reading the .bbappend file will > > (quite naturally) assume that, hey, that must represent a literal > > prepend since it includes the colon. > > It *is* a literal prepend - to FILESEXTRAPATHS. In your discussion > above you are conflating FILESPATH with FILESEXTRAPATHS. The former > is constructed based on the latter in conjuction with OVERRIDES; > they are not the same variable. ok, i think i finally clued in here, thanks. i was fixated on the processing when only *one* bbappend file was involved, i didn't think to back up another level. my bad. apologies. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA issue with custom recipe
I am trying to create a simple hello world recipe for a helloworld.c file. The recipe almost works except it hits a QA issue: WARNING: QA Issue: hello: Files/directories were installed but not shipped The warning leads to a failure in the do_rootfs. Base image: core-image-minimal, and here is the build output: --- Build Configuration: BB_VERSION= "1.16.0" TARGET_ARCH = "i586" TARGET_OS = "linux" MACHINE = "cedartrail" DISTRO= "poky" DISTRO_VERSION= "1.3" TUNE_FEATURES = "m32 core2" TARGET_FPU= "" meta meta-yocto meta-yocto-bsp meta-intel meta-cedartrail meta-apps = ":" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: QA Issue: hello: Files/directories were installed but not shipped /usr /usr/bin ERROR: Function failed: do_rootfs -- What am I missing in the recipe? -- Regards, Sean D. Liming Owner Annabooks Cell: 858-774-3176 DESCRIPTION = "Hello World Application" LICENSE = "GPL-2" LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58" SECTION = "apps" SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c" SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda" SRC_URI[sha256sum] = "f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d" S = "${WORKDIR}" do_compile() { ${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c -o helloyocto } do_install() { install -d ${D}${bindir} install -m 0755 helloyocto ${D}{bindir} } ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA issue with custom recipe
> I am trying to create a simple hello world recipe for a helloworld.c > file. The recipe almost works except it hits a QA issue: WARNING: QA > Issue: hello: Files/directories were installed but not shipped > > The warning leads to a failure in the do_rootfs. > > WARNING: QA Issue: hello: Files/directories were installed but not shipped >/usr >/usr/bin > ERROR: Function failed: do_rootfs > -- > > > What am I missing in the recipe? > > -- > Regards, > > Sean D. Liming > Owner > Annabooks > Cell: 858-774-3176 > > > -- next part -- > DESCRIPTION = "Hello World Application" > LICENSE = "GPL-2" > LIC_FILES_CHKSUM = > "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58" > > SECTION = "apps" > > SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c" > SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda" > SRC_URI[sha256sum] = > "f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d" > > S = "${WORKDIR}" > > do_compile() { > ${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c -o > helloyocto > } > > do_install() { > install -d ${D}${bindir} > install -m 0755 helloyocto ${D}{bindir} > } > > Sean, I think you need to note which files are installed by the packages associated with this recipe, via: FILES_${PN} = "${bindir}" For more info on these, Check out the FILES and CONFFILES variables in the Poky Reference Manual. I also found it helpful to grep around some of the bigger recipes to see how they use these. (I got a bit tripped up with some libraries with the sonames set!) Regards, Jon ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap
Hi Ioana, Seems the patch won't apply even with the --keep-cr flag. This is against jzhang/windows-build branch. Can you double check? Thanks, Jessica git am --keep-cr ~/mbox/\[yocto\]_\[PATCH_7_8\]_convert_CRLF_line_terminators_to_CR_only.mbox Applying: convert CRLF line terminators to CR only /home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:79: trailing whitespace. public FiniteStateWizard() { /home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:81: trailing whitespace. /home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:96: trailing whitespace. /home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:101: trailing whitespace. super.createPageControls(pageContainer); /home/jzhang/eclipse-poky-windows/.git/rebase-apply/patch:112: trailing whitespace. error: patch failed: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizard.java:1 error: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizard.java: patch does not apply error: patch failed: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizardPage.java:1 error: plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/FiniteStateWizardPage.java: patch does not apply Patch failed at 0001 convert CRLF line terminators to CR only When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". -Original Message- From: Grigoropol, IoanaX Sent: Thursday, December 06, 2012 6:02 AM To: Zhang, Jessica; yocto@yoctoproject.org Subject: RE: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap Hi Jessica, There seems to be a bit of a mix-up on the new branch in the order of the patches were applied. Also, some files modified under Linux have CRLF ending instead of CR. Can you please rebase the branch (the new one or the old one) to commit ec4fcf7b478f59e190d9b9fe9b56e44971c4f66c, and then apply the set of 8 patches I resent to the mailing list ? Bare in mind that the patch before last (that converts from CRLF to CR) will not apply unless applied with option --keep-cr. Thanks, Ioana -Original Message- From: Zhang, Jessica Sent: Thursday, December 06, 2012 1:12 AM To: Grigoropol, IoanaX; yocto@yoctoproject.org Subject: RE: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap Hi Ioana, None of your patches of today apply so there seems to be some rebase issue. Also, I've added headless build support changes for windows BC plugin, so can you rebase against jzhang/windows-build and resubmit the patch series? Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Ioana Grigoropol Sent: Wednesday, December 05, 2012 2:41 AM To: yocto@yoctoproject.org Subject: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap Signed-off-by: Ioana Grigoropol --- .../remote/utils/YoctoHostShellProcessAdapter.java | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java index 9ab43cf..2dba0a6 100644 --- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java +++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShe +++ llProcessAdapter.java @@ -34,6 +34,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter { private Semaphore sem; + public YoctoHostShellProcessAdapter(IHostShell hostShell, ProcessStreamBuffer processStreamBuffer, CommandResponseHandler commandResponseHandler) throws IOException { super(hostShell); this.processStreamBuffer = processStreamBuffer; @@ -41,7 +42,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter { this.calculator = new GitCalculatePercentage(); this.sem = new Semaphore(1); this.command = ""; - this.commandMonitors = new HashMap<>(); + this.commandMonitors = new HashMap(); } public String getLastCommand() { @@ -50,7 +51,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter { public synchronized void setLastCommand(String lastCommand) { try { - // there are still some processes that might take a long time and if we do not wait for them, + // there are still some processes that might take a long time and if +we do not wait for them, // then the semaphore will not be released, because an interrupted exception will occur Thread.sleep(2000); i
Re: [yocto] [PATCH] Yocto Project Dev Manual - bad reference in dev-manual-newbie.xml
This patch has been applied to the master branch of yocto-docs repo. I have republished the dev-manual in the "In Progress" documents on the YP website. Thanks for the patch Bob. Scott >-Original Message- >From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Bob Cochran >Sent: Saturday, December 01, 2012 7:15 AM >To: Yocto discussion list >Subject: [yocto] [PATCH] Yocto Project Dev Manual - bad reference in >dev-manual-newbie.xml > >I updated a note that points the reader to the maintainers list. The >note in the master branch pointed the reader to a nonexistent (old) >file. > >Signed-off-by: Robert Cochran > >--- > documentation/dev-manual/dev-manual-newbie.xml |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/documentation/dev-manual/dev-manual-newbie.xml >b/documentation/dev-manual/dev-manual-newbie.xml >index bb01131..8b078e1 100644 >--- a/documentation/dev-manual/dev-manual-newbie.xml >+++ b/documentation/dev-manual/dev-manual-newbie.xml >@@ -742,8 +742,8 @@ > The maintainer is responsible for allowing changes in from >other developers and for > organizing the underlying branch structure to reflect release >strategies and so forth. > You can see who is the maintainer for Yocto Project >files by examining the >-distro_tracking_fields.inc file in the >Yocto Project >-meta/conf/distro/include directory. >+maintainers.inc file in the Yocto Project >+meta-yocto/conf/distro/include >directory. > > > >-- >1.7.9.5 >___ >yocto mailing list >yocto@yoctoproject.org >https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/8][eclipse-poky] Enable setting yocto settings in the project properties dialog
Hi Timo, Great patch set and merged to eclipse-poky master. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of m...@timomueller.eu Sent: Tuesday, December 04, 2012 1:22 AM To: yocto@yoctoproject.org Cc: Timo Mueller Subject: [yocto] [PATCH 0/8][eclipse-poky] Enable setting yocto settings in the project properties dialog From: Timo Mueller Hi, changing the yocto settings of a project is currently achieved through a separate dialog. This dialog can be opened via the eclipse menu bar (project -> change yocto project settings). Typically all project related settings in eclipse are located in the project properties dialog. This patch series adds yocto settings to the project properties dialog. It also removes the separate dialog. Instead the yocto section in the project properties is opened if "change yocto project settings" is selected from the menu bar. Best regards, Atanas and Timo Atanas Gegov (4): plugins/sdk.ide: Allow using a YoctoUIElement to set the input of a yocto settings widget plugins/sdk.ide: Create a default YoctoUIElement from the preference store plugins/sdk.ide: Use new setCurrentInput method to set defaults plugins/sdk.ide: Remove fControl array that is no longer needed Timo Mueller (4): plugins/sdk.ide: Added empty yocto preference page to project properties plugins/sdk.ide: Move modification of yocto project settings to utils class plugins/sdk.ide: Show yocto ui setting widget in project property page plugins/sdk.ide: Open project properties instead of standalone yocto settings dialog .../OSGI-INF/l10n/bundle.properties|1 + plugins/org.yocto.sdk.ide/plugin.xml | 14 +++ .../src/org/yocto/sdk/ide/YoctoSDKUtils.java | 67 .../src/org/yocto/sdk/ide/YoctoUISetting.java | 54 +++--- .../yocto/sdk/ide/actions/ReconfigYoctoAction.java | 64 ++- .../yocto/sdk/ide/actions/SDKLocationDialog.java | 89 .../ide/preferences/YoctoSDKPreferencePage.java| 51 +- .../preferences/YoctoSDKProjectPropertyPage.java | 111 8 files changed, 247 insertions(+), 204 deletions(-) delete mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/actions/SDKLocationDialog.java create mode 100644 plugins/org.yocto.sdk.ide/src/org/yocto/sdk/ide/preferences/YoctoSDKProjectPropertyPage.java -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/3][eclipse-poky] Add option to allow building from local repo
Hi Timo, There're some changes made to eclipse build scripts, so your patch won't be able to apply. Can you rebase against latest master and resend? Thanks, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of m...@timomueller.eu Sent: Friday, November 30, 2012 2:33 AM To: yocto@yoctoproject.org Cc: Timo Mueller Subject: [yocto] [PATCH 0/3][eclipse-poky] Add option to allow building from local repo From: Timo Mueller Hi, if you build eclipse-poky with the provided build script it will always use the upstream version of the IDE. During development I wanted to use my local repository to make sure that my changes don't break the build system. Therefor I added an option to the build script to allow building from the local eclipse-poky git repository. Best regards, Timo Timo Mueller (3): scripts/build.sh: Added function to use the local repository for building scripts/build.sh: Added help option to the cmdline script/build.sh: Added option to enable building from local repository. scripts/build.sh | 30 ++ 1 files changed, 26 insertions(+), 4 deletions(-) -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA issue with custom recipe
> -Original Message- > From: Jon Szymaniak [mailto:jon.szyman...@gmail.com] > Sent: Friday, December 07, 2012 1:36 PM > To: sean.lim...@annabooks.com > Cc: yocto@yoctoproject.org > Subject: Re: QA issue with custom recipe > > > I am trying to create a simple hello world recipe for a helloworld.c > > file. The recipe almost works except it hits a QA issue: WARNING: QA > > Issue: hello: Files/directories were installed but not shipped > > > > The warning leads to a failure in the do_rootfs. > > > > WARNING: QA Issue: hello: Files/directories were installed but not shipped > >/usr > >/usr/bin > > ERROR: Function failed: do_rootfs > > -- > > > > > > What am I missing in the recipe? > > > > -- > > Regards, > > > > Sean D. Liming > > Owner > > Annabooks > > Cell: 858-774-3176 > > > > > > -- next part -- DESCRIPTION = "Hello World > > Application" > > LICENSE = "GPL-2" > > LIC_FILES_CHKSUM = > > "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58" > > > > SECTION = "apps" > > > > SRC_URI = "file:///home/sean/workspace/Hello/HelloYocto.c" > > SRC_URI[md5sum] = "4f5c57b446cc08a7299d4dca58c49cda" > > SRC_URI[sha256sum] = > > > "f357d9214f9c585d8b3997c6a3038eb28b218de264a8bb39ae8474949ad2b98d" > > > > S = "${WORKDIR}" > > > > do_compile() { > > ${CC} ${CFLAGS} ${LDFLAGS} /home/sean/workspace/Hello/HelloYocto.c - > o > > helloyocto } > > > > do_install() { > > install -d ${D}${bindir} > > install -m 0755 helloyocto ${D}{bindir} } > > > > > > Sean, > > I think you need to note which files are installed by the packages > associated with this recipe, via: > > FILES_${PN} = "${bindir}" > > For more info on these, Check out the FILES and CONFFILES > variables in the Poky Reference Manual. I also found it helpful > to grep around some of the bigger recipes to see how they use > these. (I got a bit tripped up with some libraries with the sonames set!) > > > Regards, > Jon John, Thank you. The Q/A Warning is gone. That is one step closer, but the package is still not resolved. - Processing HelloYocto... Unable to resolve package HelloYocto ERROR: some packages were missing ERROR: Function failed: do_rootfs (see /home/sean/Yocto1.3/n2800/tmp/work/cedartrail-poky-linux/core-image-minimal- 1.0-r0/temp/log.do_rootfs.24265 for further information) -- Regards, Sean Liming Owner Annabooks Tel: 714-970-7523 / Cell: 858-774-3176 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto