1. Yocto
  2. Topics

project that builds target and host

Joel Winarske
 

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
Ross Burton <ross@...>
 

On Wed, 13 May 2020 at 06:03, Joel Winarske <joel.winarske@...> 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
Joel Winarske
 

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@...> wrote:
On Wed, 13 May 2020 at 06:03, Joel Winarske <joel.winarske@...> 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
Ross Burton <ross@...>
 

On Wed, 13 May 2020 at 20:28, Joel Winarske <joel.winarske@...> 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
Joel Winarske
 

What are some nasty hack options?  

The major surgery would be less maintainable.

On Wed, May 13, 2020, 12:51 PM Ross Burton <ross@...> wrote:
On Wed, 13 May 2020 at 20:28, Joel Winarske <joel.winarske@...> 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
Ross Burton <ross@...>
 

On Wed, 13 May 2020 at 21:05, Joel Winarske <joel.winarske@...> 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
Joel Winarske
 


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

1 - 7 of 7