On Thu, 2019-10-24 at 12:34 +0300, Adrian Bunk wrote: > On Thu, Oct 24, 2019 at 09:15:01AM +0100, > [email protected] wrote: > > The cmake change makes python visible from HOSTTOOLS. That isn't > > wrong > > as such, it is a change in behaviour. If recipes don't set python > > enabled/disabled explicitly, there is some fallout from that. I'd > > say > > that is a bug in those recipes which aren't giving explicit > > configuration to dependencies though. > > The problem is not about enable/disable, it is more about not > explicitly selecting the python version. > > For the affected libiio the python2 -> python3 change of the python > bindings last week [1] was basically: > > -inherit cmake pythonnative systemd > +inherit cmake python3native systemd > > This is very fragile, and I would consider it expected that either > the old or the new case will break in some way when both python2 and > python3 are available during the build.
That isn't the complete story. We changed the search path in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dbba06d9153ae588c9496b40e5db18b3602bfad1 which then meant libiio found the wrong python as "python" in PATH became py2. As you say, it doesn't specifically declare which python it wants so things changed. I admit I'd misread the recipes, both for the upgrade and enable/disable, I should know better. I think this kind of proves my point about trying to push more work onto people who are already overworked though. The key questions: * is that OE-Core change is correct? * should this recipe be more explicit about its configuration? * are there other places this problem has been introduced? * who is responsible for fixing any further issues? While we remember we should document this for the 3.1 migration guide at the very least. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
