project that builds target and host

project that builds target and host

[Joel Winarske]

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

Hi,

I have a project that generates a native artifact during the target build.
Both the native and target artifacts are needed for other target recipes.

What's the recommended pattern for handling this?


Thanks,
Joel

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

Re: [yocto] project that builds target and host

[Ross Burton]

On Wed, 13 May 2020 at 06:03, Joel Winarske <joel.winarske@gmail.com> wrote:
> I have a project that generates a native artifact during the target build.  Both the native and target artifacts are needed for other target recipes.
>
> What's the recommended pattern for handling this?

Either use BBCLASSEXTEND or write a -native recipe, build just the
native parts in a foo-native recipe and depend on that to build foo
and other recipes.

For example, glib-2.0 DEPENDS on glib-2.0-native.

Ross

Re: [yocto] project that builds target and host

[Joel Winarske]

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

Hi Ross,

Yes I've done what you mention before.

In this case I already have a Target and Native recipe.  The Project
generates a Native artifact when building the Target.  Not resolvable
without major surgery.  This artifact is then required in other Target
recipes.


Joel

On Wed, May 13, 2020, 7:13 AM Ross Burton <ross@burtonini.com> wrote:

> On Wed, 13 May 2020 at 06:03, Joel Winarske <joel.winarske@gmail.com>
> wrote:
> > I have a project that generates a native artifact during the target
> build.  Both the native and target artifacts are needed for other target
> recipes.
> >
> > What's the recommended pattern for handling this?
>
> Either use BBCLASSEXTEND or write a -native recipe, build just the
> native parts in a foo-native recipe and depend on that to build foo
> and other recipes.
>
> For example, glib-2.0 DEPENDS on glib-2.0-native.
>
> Ross
>

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

Re: [yocto] project that builds target and host

[Ross Burton]

On Wed, 13 May 2020 at 20:28, Joel Winarske <joel.winarske@gmail.com> wrote:
> In this case I already have a Target and Native recipe.  The Project generates a Native artifact when building the Target.  Not resolvable without major surgery.  This artifact is then required in other Target recipes.

A target recipe can't drop files into the native sysroot, so it's
either nasty hacks or major surgery.

Ross

Re: [yocto] project that builds target and host

[Joel Winarske]

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

What are some nasty hack options?

The major surgery would be less maintainable.

On Wed, May 13, 2020, 12:51 PM Ross Burton <ross@burtonini.com> wrote:

> On Wed, 13 May 2020 at 20:28, Joel Winarske <joel.winarske@gmail.com>
> wrote:
> > In this case I already have a Target and Native recipe.  The Project
> generates a Native artifact when building the Target.  Not resolvable
> without major surgery.  This artifact is then required in other Target
> recipes.
>
> A target recipe can't drop files into the native sysroot, so it's
> either nasty hacks or major surgery.
>
> Ross
>

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

Re: [yocto] project that builds target and host

[Ross Burton]

On Wed, 13 May 2020 at 21:05, Joel Winarske <joel.winarske@gmail.com> wrote:
> What are some nasty hack options?

Putting files in the target sysroot that are in fact native binaries.
Don't do that.

> The major surgery would be less maintainable.

Can you not work with upstream to integrate the changes?
Alternatively, if the native parts are relatively simple, you can just
build them directly.

Ross

Re: [yocto] project that builds target and host

[Joel Winarske]

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

>
>
> Putting files in the target sysroot that are in fact native binaries.
> Don't do that.
>

Yeah i don't want to disable stripping the Target files.


> > The major surgery would be less maintainable.
>
> Can you not work with upstream to integrate the changes?
> Alternatively, if the native parts are relatively simple, you can just
> build them directly.
>

Well actually, I'll take a look at patching the tree with a custom
CMakeLists.txt file.  It may not be that bad.

Thanks Ross

>

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