All of lore.kernel.org
 help / color / mirror / Atom feed
* -staticdev packages not in sdk
@ 2019-08-06 14:04 Koeller, Thomas
  2019-08-06 22:06 ` Richard Purdie
  0 siblings, 1 reply; 3+ messages in thread
From: Koeller, Thomas @ 2019-08-06 14:04 UTC (permalink / raw)
  To: yocto

Hi,

browsing the list archives I came across an older thread that exactly describes the problem I am currently struggling with:

https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html

In short, I have a recipe that produces only a couple of header files and a single static library, nothing to be installed on the target. So the base package is empty, which is why I have 'ALLOW_EMPTY_${PN} = "1"' in its recipe. In my image definition I have 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', so I expect the -staticdev package to be included when generating the SDK. This is, however, not the case. While a large number of -staticdev packages from different recipes is now included in the SDK, only the -dev package is included for my recipe, not the -staticdev (though the corresponding rpm is actually built and contains the library as expected, it just is not installed).

The archived mail thread referenced above suggests adding the base package ${PN} to IMAGE_INSTALL, which indeed does work for me. However, I do not understand why this is necessary at all, as my package is already referenced from another recipe by being listed in that recipe's DEPENDS variable, shouldn't that be enough? Also, the -dev package gets installed into the SDK even without such cruft. As far as I can see, identical logic is applied to both -dev and -staticdev packages, so what is the difference?

I also found a different workaround for the problem: listing the -staticdev package in TOOLCHAIN_TARGET_TASK. Needless to say, this workaround is just as undesirable as the former one.

I am using the sumo branch.

Thomas


Thomas Koeller
Senior Software Developer


Basler AG
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 4102 463 390
Fax +49 4102 463 46 390


Thomas.Koeller@baslerweb.com
www.baslerweb.com

Management board: Dr.-Ing. Dietmar Ley (CEO) · John P. Jennings · Arndt Bake · Hardy Mehl
Chairman of the supervisory board: Norbert Basler
Basler AG · Amtsgericht Lübeck HRB 4090 · Ust-IdNr.: DE 135 098 121 · Steuer-Nr.: 30 292 04497 · WEEE-Reg.-Nr. DE 83888045

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: -staticdev packages not in sdk
  2019-08-06 14:04 -staticdev packages not in sdk Koeller, Thomas
@ 2019-08-06 22:06 ` Richard Purdie
  2019-08-07  9:06   ` Koeller, Thomas
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Purdie @ 2019-08-06 22:06 UTC (permalink / raw)
  To: Koeller, Thomas, yocto

On Tue, 2019-08-06 at 14:04 +0000, Koeller, Thomas wrote:
> browsing the list archives I came across an older thread that exactly
> describes the problem I am currently struggling with:
> 
> https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html
> 
> In short, I have a recipe that produces only a couple of header files
> and a single static library, nothing to be installed on the target.
> So the base package is empty, which is why I have 'ALLOW_EMPTY_${PN}
> = "1"' in its recipe. In my image definition I have
> 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', so I expect the
> -staticdev package to be included when generating the SDK. This is,
> however, not the case. While a large number of -staticdev packages
> from different recipes is now included in the SDK, only the -dev
> package is included for my recipe, not the -staticdev (though the
> corresponding rpm is actually built and contains the library as
> expected, it just is not installed).
> 
> The archived mail thread referenced above suggests adding the base
> package ${PN} to IMAGE_INSTALL, which indeed does work for me.
> However, I do not understand why this is necessary at all, as my
> package is already referenced from another recipe by being listed in
> that recipe's DEPENDS variable, shouldn't that be enough?

DEPENDS means its a *build* time dependency. Since nothing links to it
there is no runtime dependency generated and this empty package you've
created is never installed into the image.

If its not installed into the image, the SDK for that image won't have
the corresponding -dev package.

If you add an RDEPENDS on the empty package to something in the image,
you'll probably find the -dev package then is installed.

>  Also, the -dev package gets installed into the SDK even without such
> cruft. As far as I can see, identical logic is applied to both -dev
> and -staticdev packages, so what is the difference?
> 
> I also found a different workaround for the problem: listing the
> -staticdev package in TOOLCHAIN_TARGET_TASK. Needless to say, this
> workaround is just as undesirable as the former one.

Cheers,

Richard



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: -staticdev packages not in sdk
  2019-08-06 22:06 ` Richard Purdie
@ 2019-08-07  9:06   ` Koeller, Thomas
  0 siblings, 0 replies; 3+ messages in thread
From: Koeller, Thomas @ 2019-08-07  9:06 UTC (permalink / raw)
  To: yocto

>On Tue, 2019-08-06 at 14:04 +0000, Koeller, Thomas wrote:
>> browsing the list archives I came across an older thread that exactly
>> describes the problem I am currently struggling with:
>>
>> https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html
>>
>> In short, I have a recipe that produces only a couple of header files
>> and a single static library, nothing to be installed on the target.
>> So the base package is empty, which is why I have 'ALLOW_EMPTY_${PN}
>> = "1"' in its recipe. In my image definition I have
>> 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', so I expect the
>> -staticdev package to be included when generating the SDK. This is,
>> however, not the case. While a large number of -staticdev packages
>> from different recipes is now included in the SDK, only the -dev
>> package is included for my recipe, not the -staticdev (though the
>> corresponding rpm is actually built and contains the library as
>> expected, it just is not installed).
>>
>> The archived mail thread referenced above suggests adding the base
>> package ${PN} to IMAGE_INSTALL, which indeed does work for me.
>> However, I do not understand why this is necessary at all, as my
>> package is already referenced from another recipe by being listed in
>> that recipe's DEPENDS variable, shouldn't that be enough?
>
> DEPENDS means its a *build* time dependency. Since nothing links to it
> there is no runtime dependency generated and this empty package you've
> created is never installed into the image.
>
> If its not installed into the image, the SDK for that image won't have
> the corresponding -dev package.

But the -dev image is in fact installed, it is the -staticdev that is
not.

> If you add an RDEPENDS on the empty package to something in the image,
> you'll probably find the -dev package then is installed.

Meanwhile, I tried a different approach:

In bitbake.conf there is a line
    DEPCHAIN_POST = "-dev -dbg"
that causes -dev and -dbg packages to pull in the respective packages
generated by recipes that are dependencies. This seemed to explain why
-dev packages were chained while -staticdev were not. I appended
" -staticdev" to that variable (in my image recipe), which IMHO should
be the default. I do not see any reason why -staticdev packages should
be treated differently from -dev in this respect.

Then, I used
    ALLOW_EMPTY_${PN}-staticdev = "1"
in my dependent recipe, because that one does not produce a non-empty
-staticdev package.

I chose that approach because to me it appeared to be the cleanest way
to address the problem. Too bad it doesn't work, still only the -dev
packages are included in the SDK. Any idea as to why this did not work
out?

>>  Also, the -dev package gets installed into the SDK even without such
>> cruft. As far as I can see, identical logic is applied to both -dev
>> and -staticdev packages, so what is the difference?
>>
>> I also found a different workaround for the problem: listing the
>> -staticdev package in TOOLCHAIN_TARGET_TASK. Needless to say, this
>> workaround is just as undesirable as the former one.


Thomas Koeller
Senior Software Developer


Basler AG
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 4102 463 390
Fax +49 4102 463 46 390


Thomas.Koeller@baslerweb.com
www.baslerweb.com

Management board: Dr.-Ing. Dietmar Ley (CEO) · John P. Jennings · Arndt Bake · Hardy Mehl
Chairman of the supervisory board: Norbert Basler
Basler AG · Amtsgericht Lübeck HRB 4090 · Ust-IdNr.: DE 135 098 121 · Steuer-Nr.: 30 292 04497 · WEEE-Reg.-Nr. DE 83888045

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-08-07  9:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-06 14:04 -staticdev packages not in sdk Koeller, Thomas
2019-08-06 22:06 ` Richard Purdie
2019-08-07  9:06   ` Koeller, Thomas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.