Hi Victor, Zang,
How do you with to go forward ?
There was at least the issue quoted below to resolve wrt my patches. Do we
want to wait for 4.4 to hit
master or is it something we can tackle already ?
Victor wrote:
>> OK, for some reason I had missed that it does indeed achieve that.
Maybe we should add more doc about that.
>>
>> The split of a -runtime package, however, allows to still build the
"translator" part, not have it installed in the image
>> shipped on product, but still have the ability to install it from the
feed while developing, should someone prefer
>> this to cross-building the probes. Not a big deal if you prefer not to
do that however, my own use-case would be
>> covered by the PACKAGECONFIG="monitor".
>
> Yes, I was thinking about this use case as well. But it is quite esoteric
for OE. Furthermore,
> it kind of contradicts current PACKAGECONFIG structure. If we want to go
this route we need
> to reshuffle the whole thing in a different way. I.e either use
PACKAGECONFIG to
> control the content systemtap package or use subpackages. Using both
looks a bit convoluted.
It does not see contradictory to me to have PACKAGECONFIG triggering
generation of material that will
in turn de/activate packages. Maybe we should align the naming of
PACKAGECONFIG
options and
related binary packages ?
As for myself I find the "translator" and "monitor" names not really
intuitive, they just match upstream
config option naming. What about starting by renaming "monitor" to
"runtime" and making sure all files
generated with PACKAGECONFIG="runtime" get into ${PN}-runtime ?
As for "translator", it seems to refer to what most of us think about as a
"compiler", would that fit ?
We could then move those files into ${PN}-compiler and leave ${PN} as a
virtual package pulling
-runtime and -compiler.
Does this look correct ?
Le mar. 17 nov. 2020 à 10:24, Richard Purdie <
richard.pur...@linuxfoundation.org> a écrit :
> On Mon, 2020-11-16 at 20:34 -0800, Victor Kamensky wrote:
> > Hi Yann and Richard,
> >
> > On Fri, Nov 13, 2020 at 5:59 AM Yann Dirson <
> > yann.dir...@blade-group.com> wrote:
> > >
> > > Oh I did not notice, shouldn't we be discussing this on-list ?
> >
> > Very sorry about this. I did not notice that I've unintentionally
> > removed the mailing list.
> > Added it back.
> >
> > I see that Richard added your patches to master-next. But I don't
> > think they should be
> > merged "as is". IMO we need to work more on them.
> >
> > Richard, could you please hold off merging them?
>
> Sorry, they did merge already around a day ago. Yann had proposed them
> a while ago and spent quite a bit of time sorting out the automated
> testing failures so it felt like we should merge them since there was
> no feedback otherwise and they looked basically reasonable to me.
>
> Obviously we can follow up with other improvements to build upon them
> though.
>
--
Yann Dirson <y...@blade-group.com>
Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145174):
https://lists.openembedded.org/g/openembedded-core/message/145174
Mute This Topic: https://lists.openembedded.org/mt/78211639/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
