On Wed, May 15 2024 at 03:44:46 PM +00:00:00, Peter Kjellerstedt
<[email protected]> wrote:
Iflibmalcontent-uilinks withlibmalcontent, then
themalcontent-uirecipe should have aDEPENDSonmalcontent, and you
should not need to add an explicitRDEPENDS:${PN}for it (just as
Martin wrote).
The reason I guess that you get that error is because I believe
themalcontent-uirecipe has actually builtlibmalcontentitself (given
that both recipes use the same source code) rather than using the one
produced by themalcontentrecipe (whichmalcontent-uidoesn’t depend
on…) Would it be an option to just have one recipe that builds both
libraries and then packages them in different packages?
I also suspect that this is the reason.
There have been problems with a circular dependency if built with
-Dui=enabled.
This will therefore probably not work.
There are different approaches in malcontent to work around this
problem.
You can use system malcontent:
https://gitlab.freedesktop.org/pwithnall/malcontent/-/blob/main/meson_options.txt?ref_type=heads#L18
But this is not suitable, and building malcontent-native does not seem
to be a good way either, as it has quite heavy dependencies. malcontent
still offers this way:
https://gitlab.freedesktop.org/pwithnall/malcontent/-/commit/fda2fbd33084a388effc844ab73fd4f2c297efb1
Also (since I now looked at the recipes), I would strongly recommend
not to do:
FILES:${PN} = "${bindir} ${libdir} ${datadir}"
as you do in themalcontent-uirecipe, or:
FILES:${PN} += "${libdir} ${datadir}"
as you do in themalcontentrecipe. Resetting FILES:${PN} (as in the
first case) is always a source of problems and can easily lead to
incorrect packaging of files. And for${libdir}and${datadir}, be more
specific with what paths you are actually adding.
I agree that in principle you have better control over which files are
shipped if being more specific in FILES:${PN}. But in this particular
case, we already explicitly specify each file to be installed in
do_install to avoid multiple providers. So we already have control over
what is installed/shipped. Duplicating this to FILES:${PN} would mean
that we would have to make all changes twice during a recipe update if
we additionally specified each file in FILES:${PN}?
//Peter
*From:*[email protected]
<[email protected]> *On Behalf Of*Markus Volk
*Sent:* den 13 maj 2024 23:04
*To:* Martin Jansa <[email protected]>
*Cc:* [email protected]; [email protected]
*Subject:* Re: [oe] [meta-oe][PATCH 1/2] malcontent-ui: add
malcontent to RDEPENDS
On Mon, May 13 2024 at 10:30:31 PM +02:00:00, Martin Jansa
<[email protected] <mailto:[email protected]>> wrote:
If libmalcontent-ui-1.so.1 links with libmalcontent-0.so.0 then this
should be build-time DEPENDS (and then shlibs code in do_package
will automatically add malcontent to RDEPENDS.
This error is caused by adding malcontent to the DEPENDS field in
PACKAGECONFIG like I did in gnome-control-center. After enabling this
in my build the error occurred.
But in the end this RDPEND is not wrong I guess? I've split the
package in two and without this RDEPEND it would be possible to
install libmalcontent-ui without libmalcontent which would then be
broken
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#110417):
https://lists.openembedded.org/g/openembedded-devel/message/110417
Mute This Topic: https://lists.openembedded.org/mt/106081394/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
