What criteria are categorized? (tmp/work/...)

What criteria are categorized? (tmp/work/...)

[윤영석]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

After poky the build, i look at the tmp/work folder.
I can see these folders.
All-poky-linux / i586-poky-linux / qemux86-poky-linux / x86_64-linux /
 
What is the classification of each folder?
What options should I set in recipes?
 
Thanks

[-- Attachment #2: Type: text/html, Size: 714 bytes --]

Re: What criteria are categorized? (tmp/work/...)

[Paul Eggleton]

On Tue, 29 Nov 2016 11:47:40 윤영석 wrote:
> After poky the build, i look at the tmp/work folder.
> I can see these folders.
> All-poky-linux / i586-poky-linux / qemux86-poky-linux / x86_64-linux /
> 
> What is the classification of each folder?

That directory level corresponds to MULTIMACH_TARGET_SYS, whose value is
"${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}". The first variable
PACKAGE_ARCH has a default value of "${TUNE_PKGARCH}" which makes a recipe
architecture-specific by default. PACKAGE_ARCH is often set in the recipe
in two common cases:

1) Recipes which are packaging something that is not architecture-specific -
these should "inherit allarch" which will automatically set
PACKAGE_ARCH = "all". Note that in this situation you should use
"inherit allarch" rather than setting PACKAGE_ARCH yourself since that is
not the only thing that the allarch class takes care of.

2) Recipes which are packaging something that is machine-specific - these
should set PACKAGE_ARCH = "${MACHINE_ARCH}".

Additionally, recipes that are building for the build host rather than the
target machine (*-native) or for the SDK (nativesdk-*) get different values
for  MULTIMACH_TARGET_SYS as well, but this is accomplished by inheriting
the native or nativesdk classes or using BBCLASSEXTEND to create a variant
of the recipe for one or both.

> What options should I set in recipes?

Can you be more precise about what you want to do?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: What criteria are categorized? (tmp/work/...)

[윤영석]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

I want to split the package that belongs to host and target in one recipes. 
 
Thanks.
 
-----Original Message-----
From: "Paul Eggleton"<paul.eggleton@linux.intel.com> 
To: "윤영석"<earwigz@naver.com>; 
Cc: <yocto@yoctoproject.org>; 
Sent: 2016-11-29 (화) 13:15:12
Subject: Re: [yocto] What criteria are categorized? (tmp/work/...)
 
On Tue, 29 Nov 2016 11:47:40 윤영석 wrote:
> After poky the build, i look at the tmp/work folder.
> I can see these folders.
> All-poky-linux / i586-poky-linux / qemux86-poky-linux / x86_64-linux /
> 
> What is the classification of each folder?

That directory level corresponds to MULTIMACH_TARGET_SYS, whose value is
"${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}". The first variable
PACKAGE_ARCH has a default value of "${TUNE_PKGARCH}" which makes a recipe
architecture-specific by default. PACKAGE_ARCH is often set in the recipe
in two common cases:

1) Recipes which are packaging something that is not architecture-specific -
these should "inherit allarch" which will automatically set
PACKAGE_ARCH = "all". Note that in this situation you should use
"inherit allarch" rather than setting PACKAGE_ARCH yourself since that is
not the only thing that the allarch class takes care of.

2) Recipes which are packaging something that is machine-specific - these
should set PACKAGE_ARCH = "${MACHINE_ARCH}".

Additionally, recipes that are building for the build host rather than the
target machine (*-native) or for the SDK (nativesdk-*) get different values
for  MULTIMACH_TARGET_SYS as well, but this is accomplished by inheriting
the native or nativesdk classes or using BBCLASSEXTEND to create a variant
of the recipe for one or both.

> What options should I set in recipes?

Can you be more precise about what you want to do?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


[-- Attachment #2: Type: text/html, Size: 2585 bytes --]

Re: What criteria are categorized? (tmp/work/...)

[Paul Eggleton]

On Tue, 29 Nov 2016 14:08:27 윤영석 wrote:
> I want to split the package that belongs to host and target in one recipes.

It's actually quite difficult to do that in one recipe, because you have to 
set up the environment for the host and target correctly and run the build 
twice. Typically we avoid that pain by creating two recipes, or using 
BBCLASSEXTEND = "native" to create a native variant within the same recipe - 
see meta/recipes-devtools/bison/bison_3.0.4.bb for an example of the latter
(you just need to use the _class-native override to set anything you want to 
set specific to the build host, and if necessary _class-target to set things 
specific to the target).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: What criteria are categorized? (tmp/work/...)

[Patrick Ohly]

On Tue, 2016-11-29 at 17:15 +1300, Paul Eggleton wrote:
> On Tue, 29 Nov 2016 11:47:40 윤영석 wrote:
> > After poky the build, i look at the tmp/work folder.
> > I can see these folders.
> > All-poky-linux / i586-poky-linux / qemux86-poky-linux / x86_64-linux /
> > 
> > What is the classification of each folder?
> 
> That directory level corresponds to MULTIMACH_TARGET_SYS, whose value is
> "${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}". The first variable
> PACKAGE_ARCH has a default value of "${TUNE_PKGARCH}" which makes a recipe
> architecture-specific by default. PACKAGE_ARCH is often set in the recipe
> in two common cases:
> 
> 1) Recipes which are packaging something that is not architecture-specific -
> these should "inherit allarch" which will automatically set
> PACKAGE_ARCH = "all". Note that in this situation you should use
> "inherit allarch" rather than setting PACKAGE_ARCH yourself since that is
> not the only thing that the allarch class takes care of.
> 
> 2) Recipes which are packaging something that is machine-specific - these
> should set PACKAGE_ARCH = "${MACHINE_ARCH}".

That's three cases - "all archictures", "machine", "target archicture",
which makes sense. For example, linux-yocto and base-files are
machine-specific and thus in qemux86-poky-linux.

But when using meta-intel and MACHINE=intel-corei7-64 (at least in Ostro
OS, haven't tried with Poky), the kernel ends up in
corei7-64-intel-common-ostro-linux together with gnu-efi and
intel-microcode, while base-files and the other machine specific recipes
are in intel_corei7_64-ostro-linux.

For qemux86 and linux-yocto, PACKAGE_ARCH=MACHINE_ARCH="qemux86".
For intel-corei7-64 and linux-yocto,
PACKAGE_ARCH=INTEL_COMMON_PACKAGE_ARCH="corei7-64-intel-common" (from
meta-intel/conf/machine/include/intel-common-pkgarch.inc).

I suppose that's because the same kernel can be used by multiple
machines, so there's basically a forth level of sharing.

I just wish that the naming of the resulting directories was a bit more
intuitive. I'm constantly wondering what's in
"corei7-64-intel-common-ostro-linux" and what's in
"intel_corei7_64-ostro-linux" :-/

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.