On Mon, 2022-02-07 at 16:30 +0100, yoctoproj...@neumann-web.eu wrote:
> 
> thank you for your reply and please excuse that I didn't clarify my intent
> correctly in my first mail. Your assumption, that I meant the cmake of the SDK
> is correct. And your assumption regarding that the install path is different
> to the sysroot of the SDK toolchain is also correct.
> 
> If your statement, that multiple sysroots for building with the SDK aren't
> supported, is final, this discussion can be stopped here and we have to
> maintain extensions for that workflow in our setup. But I would like to
> explain our use case and why we require 2 sysroots for an SDK build.

We definitely don't support that usage scenario since it would be highly build
system specific and would work in some cases but not others. I do have a
suggestion of a different approach though.

> We have a set of hardware platforms which are operated by a distribution
> generated by openembedded. This is maintained by a few developers. The
> hardware
> is used in several different projects. For the project specific development
> we're using the SDK with will be installed readonly below /opt. The software
> for these different projects can be developed without knowledge that
> openembedded was used underneath. For that we have tools that abstract the
> correct SDK selection, the environment sourcing and packaging of the final
> compilation. And then tools which handle the deployment on the hardware.
> 
> Because a SDK is specific for a hardware platform, but not for a project using
> that hardware platform, it is readonly and can be used for all projects with
> this hardware. This however requires that the compiled libraries generated
> with
> this SDK during the user side build process will be installed at a different
> location, which would be the second sysroot.
> 
> Until now we only build a cmake project with external dependencies to the
> installed SDK using this workflow. Further external libraries, not contained
> in
> the SDK, had to be integrated in this cmake build, either as subdirectory or
> via external builds (using e.g. cmake-superbuilds). We now want to extend this
> workflow by supporting multiple cmake projects with dependencies to each
> other,
> thus the need for this second sysroot in the build.

Have you considered creating a sysroot per project with a copy of the sysroot
files?

This sounds like a crazy idea at first but with hardlinks for the files it is
fast and efficient to create these sysroot file trees. This is exactly what
OpenEmbedded does internally and how we handle this in our builds.

Cheers,

Richard








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161507): 
https://lists.openembedded.org/g/openembedded-core/message/161507
Mute This Topic: https://lists.openembedded.org/mt/88743247/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to