On Mon, 12 Feb 2024, Alex Kiernan wrote:

> On Mon, Feb 12, 2024 at 12:17 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> > On Mon, 12 Feb 2024, Ross Burton wrote:
> >
> > > On 12 Feb 2024, at 06:39, Robert P. J. Day via lists.openembedded.org <rpjday=crashcourse.ca@lists.openembedded.org> wrote:
> > > >  more annoying nitpickery ... here:
> > > >
> > > > https://git.openembedded.org/openembedded-core/tree/meta/recipes-extended/xz/xz_5.4.5.bb#n28
> > > >
> > > > it's not clear why someone would go to the trouble of conditionally
> > > > including run-ptest in SRC_URI as i would have thought the only
> > > > benefit would be to avoid the triviality of copying run-ptest into
> > > > WORKDIR, but beyond that, i don't see what the point is, and that's
> > > > the only recipe i've run across that bothers to do that.
> > > >
> > > >  is there something more subtle happening here?
> > >
> > > No good reason, and I’d approve a patch that removed the
> > > conditionals on the grounds of cleaning up the recipe and ensuring
> > > that there’s less conditional paths through the recipe.
> >
> >   it gets even stranger when you have a conditional to apply a test
> > patch, like here:
> >
> > https://git.openembedded.org/meta-openembedded/tree/meta-networking/recipes-protocols/freediameter/freediameter_1.4.0.bb#n21
> >
> >   i am also assuming that it's cleaner to conditionally check for
> > ptest assignment for stuff like SRC_URI and DEPENDS, not with:
> >
> >   ${@bb.utils.contains('DISTRO_FEATURES', 'ptest' ...
> >
> > but with the more intuitive:
> >
> >   ${@bb.utils.contains('PTEST_ENABLED', '1', ...
> >
>
> The PTEST_ENABLED version has the advantage that disabling ptest for a
> single recipe is much easier. I guess you could manipulate
> DISTRO_FEATURES on a per-recipe basis, but that feels awful.

  so you're confirming that the second form is equivalent, and more
intuitive? i just wanted to make sure (again) that there was no
subtlety i was overlooking.

rday