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
