Re: [yocto] staging of native header file to non-native package

2013-06-07 Thread Hans Beckérus
The simplest way I found to solve this was to add the following to my recipe PACKAGES += " ${PN}-include" ${PN}-include_FILES = "foobar.h" BBCLASSEXTEND =+ "native" By doing this I could get away with one recipe for both {PN} and ${PN}-native. And all the target package needs to do is to RDEPEN

Re: [yocto] [Refactor RFC 2/9] Add remote tools classes needed for bitbake remote capabilities

2013-06-07 Thread Grigoropol, IoanaX
Hi Jessica, I have sent you a set of 8 patches that replaces the second patch (2/9). I have added the new classes incrementally and put the changes to the RemoteHelper along with the classes that are strongly linked with it. I have also sent a pull request for the whole set of patches(50). They

[yocto] [RFC PATCH 00/50] Refactor and merge windows-build to master

2013-06-07 Thread Ioana Grigoropol
This is the cover letter only for the entire patch series. The following changes since commit 57c5d62fab9bc1024a3cf1f3f840f7f3bcfd3167: Fix Thread Access exception for systemtap Dialogs (2013-05-31 15:07:01 +0300) are available in the git repository at: git://git.yoctoproject.org/poky-cont

[yocto] [RFC Refactor[v2] 8/8] Refactor RemoteHelper class

2013-06-07 Thread Ioana Grigoropol
- added utility class CommandRunnable that will be used for running a remote command in a different thread & processing the output - add RemoteMachine utility class - RemoteMachine class holds all the information needed for a remote/local machine - environment map of all v

[yocto] [RFC Refactor[v2] 2/8] Add YoctoCommand utility class

2013-06-07 Thread Ioana Grigoropol
- YoctoCommand wraps all information needed for running a remote command - the actual command string - the command arguments - the directory in which to run the remote command - a ProcessStreamBuffer that will store the output of running this particular command - th

[yocto] [RFC Refactor[v2] 7/8] Add CommandOutputProcessor utilty class

2013-06-07 Thread Ioana Grigoropol
- this is a simple implementation of the OutputProcessor abstract class - splitting the error and output lines is done by '\n' character Signed-off-by: Ioana Grigoropol --- .../yocto/remote/utils/CommandOutputProcessor.java | 43 1 file changed, 43 insertions(+) c

[yocto] [RFC Refactor[v2] 3/8] Add CommandResponseHandler implementation of ICommandResponseHandler

2013-06-07 Thread Ioana Grigoropol
- plain implementation of ICommandResponseHandler interface that prints all lines to the console stream Signed-off-by: Ioana Grigoropol --- .../org.yocto.remote.utils/META-INF/MANIFEST.MF|3 +- .../yocto/remote/utils/CommandResponseHandler.java | 44 2 files chang

[yocto] [RFC Refactor[v2] 4/8] Add ConsoleRunnable utility class

2013-06-07 Thread Ioana Grigoropol
- Console Runnable implements Runnable and is charge to display the specified console in the Console View Signed-off-by: Ioana Grigoropol --- .../org/yocto/remote/utils/ConsoleRunnable.java| 47 1 file changed, 47 insertions(+) create mode 100644 plugins/org.yocto.r

[yocto] [RFC Refactor[v2] 0/8] Split refactoring of RemoteHelper

2013-06-07 Thread Ioana Grigoropol
- this set of patches replaces patch 2/9 from first batch of patches Ioana Grigoropol (8): Move ICommandResponseHandler to org.yocto.remote.utils Add YoctoCommand utility class Add CommandResponseHandler implementation of ICommandResponseHandler Add ConsoleRunnable utility class Add Cons

[yocto] [RFC Refactor[v2] 6/8] Add OutputProcessor utility class

2013-06-07 Thread Ioana Grigoropol
- OutputProcessor class is a stub class that will be used for processing the output of a remote command - the main method of this class is processOutput() - in this method, we retrieve the bufferes needed for output and error processing (from the host shell) (u

[yocto] [RFC Refactor[v2] 5/8] Add ConsoleHelper utility class

2013-06-07 Thread Ioana Grigoropol
- ConsoleHelper class is to be used in order to find a console by a specified name and display it in the view (using ConsoleRunnble) on the GUI thread Signed-off-by: Ioana Grigoropol --- .../src/org/yocto/remote/utils/ConsoleHelper.java | 38 1 file changed, 38 insertion

[yocto] [RFC Refactor[v2] 1/8] Move ICommandResponseHandler to org.yocto.remote.utils

2013-06-07 Thread Ioana Grigoropol
Signed-off-by: Ioana Grigoropol --- .../yocto/bc/bitbake/ICommandResponseHandler.java | 15 --- .../remote/utils/ICommandResponseHandler.java | 15 +++ 2 files changed, 15 insertions(+), 15 deletions(-) delete mode 100644 plugins/org.yocto.bc.ui/src/org/yocto/b

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus
On Fri, Jun 7, 2013 at 4:21 PM, Zhang, Jessica wrote: > When you create your image, what profile did you use. Are you building one > of our existing images, e.g. core-image-minimal, etc. or it's a customized > image and if so, how did you customize your image, via layer or install extra > pack

[yocto] gnuradio on beagleboard beagleone & pandaboard

2013-06-07 Thread Edward Vidal
Hello all, I built a core-image-sato with boost-1.53.0, qt-mobility-x11-1.2.0, gsl-1.15, gnuplot-4.6.3, and gnuradio-3.6.4.1. This had the EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk dev-pkgs dbg-pkgs" set for tools-sdk dev-pkgs dbg-pkgs in the local.conf. This required adding meta-oe for the be

Re: [yocto] Application Development

2013-06-07 Thread Zhang, Jessica
When you create your image, what profile did you use. Are you building one of our existing images, e.g. core-image-minimal, etc. or it's a customized image and if so, how did you customize your image, via layer or install extra packages? I think x11 is brought in via some package dependency.

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus
On Fri, Jun 7, 2013 at 4:03 PM, Zhang, Jessica wrote: > Yes, you need those packages in your sysroot for cross development. > > Ok. But out of curiosity, why should I need X11 packages for a simple command-line based toolchain? I assume that none of these X11 packages gets copied to my target devi

Re: [yocto] Application Development

2013-06-07 Thread Zhang, Jessica
Yes, you need those packages in your sysroot for cross development. Cheers, Jessica From: satyaswaroop.dama...@gmail.com [mailto:satyaswaroop.dama...@gmail.com] On Behalf Of DAMARLA Satya Swaroop Sent: Friday, June 07, 2013 12:10 AM To: Zhang, Jessica; yocto@yoctoproject.org Subject: Re: [y

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus
On Fri, Jun 7, 2013 at 3:40 PM, Hans Beckérus wrote: > On Fri, Jun 7, 2013 at 3:34 PM, Gary Thomas wrote: >> On 2013-06-07 07:10, Hans Beckérus wrote: >>> >>> On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop >>> wrote: SHould we install development and debigging pacakages in the i

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus
On Fri, Jun 7, 2013 at 3:34 PM, Gary Thomas wrote: > On 2013-06-07 07:10, Hans Beckérus wrote: >> >> On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop >> wrote: >>> >>> SHould we install development and debigging pacakages in the images when >>> we >>> want to build a toolchain.. I mean this

Re: [yocto] Application Development

2013-06-07 Thread Gary Thomas
On 2013-06-07 07:10, Hans Beckérus wrote: On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop wrote: SHould we install development and debigging pacakages in the images when we want to build a toolchain.. I mean this "dbg-pkgs" - add -dbg packages for all installed packages #

Re: [yocto] Application Development

2013-06-07 Thread Hans Beckérus
On Fri, Jun 7, 2013 at 9:10 AM, DAMARLA Satya Swaroop wrote: > SHould we install development and debigging pacakages in the images when we > want to build a toolchain.. I mean this > > "dbg-pkgs" - add -dbg packages for all installed packages > # (adds symbol information

Re: [yocto] [Refactor RFC 4/9] Remove unused Bitbake Actions

2013-06-07 Thread Grigoropol, IoanaX
Neither of the actions is actually defined in the plugin.xml. If we need to support it, why aren't they enabled ? From: Zhang, Jessica Sent: Friday, June 07, 2013 2:57 AM To: Grigoropol, IoanaX; yocto@yoctoproject.org Subject: RE: [yocto] [Refactor RFC 4/9]

Re: [yocto] [Refactor RFC 5/9] Remove storing of init script location

2013-06-07 Thread Grigoropol, IoanaX
Hi Jessica, The reason I have remove this is that we can always find it on git. So if we at some point decide that we need to save the location of the init script, we can just look in the git log, and add it again. I do not see the point in keeping classes, methods that are not used, and which

Re: [yocto] Distributing Compilation of Yocto

2013-06-07 Thread Gary Thomas
On 2013-06-07 02:45, Paul Eggleton wrote: Hi Mike, On Thursday 06 June 2013 18:39:38 Mike Dean wrote: Can I distribute the compilation with Yocto? I found posts about using icecc to do so, and tried to set it up, but I haven't been able to get it to work correctly. I have two machines which e

Re: [yocto] Can Yocto run on host with other CPU types

2013-06-07 Thread Luo Zhenhua-B19537
> -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Friday, June 07, 2013 5:50 PM > > On Thu, 2013-06-06 at 06:48 +, Luo Zhenhua-B19537 wrote: > > Except x86/x86-64 hosts, can Yocto support to run on hosts with other > > CPU arch, e.g. ARM,

Re: [yocto] Can Yocto run on host with other CPU types

2013-06-07 Thread Richard Purdie
On Thu, 2013-06-06 at 06:48 +, Luo Zhenhua-B19537 wrote: > Except x86/x86-64 hosts, can Yocto support to run on hosts with other > CPU arch, e.g. ARM, Powerpc, etc? You mean as the system to run the builds on? In theory that would be possible although most people tend to use x86 and the other

Re: [yocto] Distributing Compilation of Yocto

2013-06-07 Thread Paul Eggleton
Hi Mike, On Thursday 06 June 2013 18:39:38 Mike Dean wrote: > Can I distribute the compilation with Yocto? I found posts about using > icecc to do so, and tried to set it up, but I haven't been able to get it > to work correctly. I have two machines which each have two Xeon quadcore > processors

[yocto] staging of native header file to non-native package

2013-06-07 Thread Hans Beckérus
Hello. We have a native package that implements a header file that is required also by another non-native package. What is the best approach to handle such a situation? I guess one option is to create two recipes for the package containing the header filer; one native and a one non-native that does

Re: [yocto] Application Development

2013-06-07 Thread DAMARLA Satya Swaroop
SHould we install development and debigging pacakages in the images when we want to build a toolchain.. I mean this "dbg-pkgs" - add -dbg packages for all installed packages # (adds symbol information for debugging/profiling) # "dev-pkgs" - add -dev packages for a