All of lore.kernel.org
 help / color / mirror / Atom feed
* Depending on other package's features.
@ 2021-11-04 21:45 Maxim Sloyko
  2021-11-05 16:33 ` [oe] " Peter Kjellerstedt
  0 siblings, 1 reply; 3+ messages in thread
From: Maxim Sloyko @ 2021-11-04 21:45 UTC (permalink / raw)
  To: openembedded-devel

Hi all,

The recipe that I'm working on for our system (let's call it A) has a
dependency on a certain feature being enabled in another package (B).
So, in B, we have:

PACKAGECONFIG[nice-feature] = "..."

and my recipe (or rather, the tool built by the recipe), needs that
feature to be enabled to work properly. What's worse, is that this is
a runtime dependency, so if somebody just forgets to enable that
feature, the image will build fine, but the tool won't work. I would
like this to be a build time failure.

My plan is to change recipe A, so that if the "nice-feature" is
enabled, the package will PROVIDE one more thing:

PROVIDES += "${PN}-nice-feature"

and in my recipe B, I'll declare this as a dependency:

RDEPENDS:${PN} += "package-a-nice-feature".

Now I'm thinking, wouldn't it be great if package A could specify
extra PROVIDES when the feature is configured? This would be similar
to the way it's done for package's R?DEPENDS:

PACKAGECONFIG ??= "f1 f2 f3 ..."
     PACKAGECONFIG[f1] = "\
                          --with-f1, \
                          --without-f1, \
                          build-deps-for-f1, \
                          runtime-deps-for-f1, \
                          runtime-recommends-for-f1, \
                          packageconfig-conflicts-for-f1 \
                          provides-for-f1 \
                          "

The last line would be a change that I propose. It looks like it would
be relatively easy to implement this in base.bbclass

What do you think? Will this be useful? Did I miss an existing way to do this?

Thanks,

-- 
-MS


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

* RE: [oe] Depending on other package's features.
  2021-11-04 21:45 Depending on other package's features Maxim Sloyko
@ 2021-11-05 16:33 ` Peter Kjellerstedt
  2021-11-06 15:42   ` Philip Balister
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Kjellerstedt @ 2021-11-05 16:33 UTC (permalink / raw)
  To: maxims@google.com, openembedded-devel

> -----Original Message-----
> From: openembedded-devel@lists.openembedded.org <openembedded-
> devel@lists.openembedded.org> On Behalf Of Maxim Sloyko via
> lists.openembedded.org
> Sent: den 4 november 2021 22:46
> To: openembedded-devel <openembedded-devel@lists.openembedded.org>
> Subject: [oe] Depending on other package's features.

This type of questions belong on the 
openembedded-core@lists.openembedded.org mailing list.

> 
> Hi all,
> 
> The recipe that I'm working on for our system (let's call it A) has a
> dependency on a certain feature being enabled in another package (B).
> So, in B, we have:
> 
> PACKAGECONFIG[nice-feature] = "..."
> 
> and my recipe (or rather, the tool built by the recipe), needs that
> feature to be enabled to work properly. What's worse, is that this is
> a runtime dependency, so if somebody just forgets to enable that
> feature, the image will build fine, but the tool won't work. I would
> like this to be a build time failure.
> 
> My plan is to change recipe A, so that if the "nice-feature" is
> enabled, the package will PROVIDE one more thing:
> 
> PROVIDES += "${PN}-nice-feature"
> 
> and in my recipe B, I'll declare this as a dependency:
> 
> RDEPENDS:${PN} += "package-a-nice-feature".

PROVIDES is for build time provides of recipes. You cannot mix it 
with RDEPENDS:${PN} which is for runtime dependencies for packages.

> Now I'm thinking, wouldn't it be great if package A could specify
> extra PROVIDES when the feature is configured? This would be similar
> to the way it's done for package's R?DEPENDS:
> 
>      PACKAGECONFIG ??= "f1 f2 f3 ..."
>      PACKAGECONFIG[f1] = "\
>                           --with-f1, \
>                           --without-f1, \
>                           build-deps-for-f1, \
>                           runtime-deps-for-f1, \
>                           runtime-recommends-for-f1, \
>                           packageconfig-conflicts-for-f1 \
>                           provides-for-f1 \
>                           "
> 
> The last line would be a change that I propose. It looks like it would
> be relatively easy to implement this in base.bbclass
> 
> What do you think? Will this be useful? Did I miss an existing way to do
> this?
> 
> Thanks,
> 
> --
> -MS

//Peter


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

* Re: [oe] Depending on other package's features.
  2021-11-05 16:33 ` [oe] " Peter Kjellerstedt
@ 2021-11-06 15:42   ` Philip Balister
  0 siblings, 0 replies; 3+ messages in thread
From: Philip Balister @ 2021-11-06 15:42 UTC (permalink / raw)
  To: Peter Kjellerstedt, maxims@google.com, openembedded-devel

Or even openembedded-architecture

On 11/5/21 12:33, Peter Kjellerstedt wrote:
>> -----Original Message-----
>> From: openembedded-devel@lists.openembedded.org <openembedded-
>> devel@lists.openembedded.org> On Behalf Of Maxim Sloyko via
>> lists.openembedded.org
>> Sent: den 4 november 2021 22:46
>> To: openembedded-devel <openembedded-devel@lists.openembedded.org>
>> Subject: [oe] Depending on other package's features.
> 
> This type of questions belong on the
> openembedded-core@lists.openembedded.org mailing list.
> 
>>
>> Hi all,
>>
>> The recipe that I'm working on for our system (let's call it A) has a
>> dependency on a certain feature being enabled in another package (B).
>> So, in B, we have:
>>
>> PACKAGECONFIG[nice-feature] = "..."
>>
>> and my recipe (or rather, the tool built by the recipe), needs that
>> feature to be enabled to work properly. What's worse, is that this is
>> a runtime dependency, so if somebody just forgets to enable that
>> feature, the image will build fine, but the tool won't work. I would
>> like this to be a build time failure.
>>
>> My plan is to change recipe A, so that if the "nice-feature" is
>> enabled, the package will PROVIDE one more thing:
>>
>> PROVIDES += "${PN}-nice-feature"
>>
>> and in my recipe B, I'll declare this as a dependency:
>>
>> RDEPENDS:${PN} += "package-a-nice-feature".
> 
> PROVIDES is for build time provides of recipes. You cannot mix it
> with RDEPENDS:${PN} which is for runtime dependencies for packages.
> 
>> Now I'm thinking, wouldn't it be great if package A could specify
>> extra PROVIDES when the feature is configured? This would be similar
>> to the way it's done for package's R?DEPENDS:
>>
>>       PACKAGECONFIG ??= "f1 f2 f3 ..."
>>       PACKAGECONFIG[f1] = "\
>>                            --with-f1, \
>>                            --without-f1, \
>>                            build-deps-for-f1, \
>>                            runtime-deps-for-f1, \
>>                            runtime-recommends-for-f1, \
>>                            packageconfig-conflicts-for-f1 \
>>                            provides-for-f1 \
>>                            "
>>
>> The last line would be a change that I propose. It looks like it would
>> be relatively easy to implement this in base.bbclass
>>
>> What do you think? Will this be useful? Did I miss an existing way to do
>> this?
>>
>> Thanks,
>>
>> --
>> -MS
> 
> //Peter
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#93845): https://lists.openembedded.org/g/openembedded-devel/message/93845
> Mute This Topic: https://lists.openembedded.org/mt/86827516/384425
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [philip@balister.org]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


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

end of thread, other threads:[~2021-11-06 15:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-04 21:45 Depending on other package's features Maxim Sloyko
2021-11-05 16:33 ` [oe] " Peter Kjellerstedt
2021-11-06 15:42   ` Philip Balister

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.