Perhaps we need to step back for a bit. Can you explain why you (i.e. Nicolas) need an older boost version in particular? Generally speaking, rolling back component versions is painful and best avoided: it requires advanced knowledge, you might spend a lot of time on it, and still don't reach a working setup.
Alex On Wed, 16 Aug 2023 at 17:02, Alex Kiernan <[email protected]> wrote: > > Boost is a particular pain point... I have a project where I need two > different, incompatible versions of boost. I left the one in the > oe-core alone, then created a new recipe boost-1.82_1.82.0 which was > mostly copied from master with these changes to boost.inc: > > diff -u /home/alexk/poky/meta/recipes-support/boost/boost.inc > recipes-support/boost/boost.inc > --- /home/alexk/poky/meta/recipes-support/boost/boost.inc > 2023-01-12 08:25:40.990099356 +0000 > +++ recipes-support/boost/boost.inc 2023-05-25 17:32:45.491123831 +0100 > @@ -69,7 +69,7 @@ > mlprefix = d.getVar("MLPREFIX") > for lib in d.getVar('BOOST_LIBS').split(): > extras.append("--with-%s" % lib) > - pkg = "boost-%s" % (lib.replace("_", "-")) > + pkg = "%s-%s" % (d.getVar("BPN"), lib.replace("_", "-")) > if "-native" in pn: > pkg = pkg + "-native" > packages.append(mlprefix + pkg) > @@ -86,9 +86,9 @@ > FILES:${PN}-graph_parallel = "${libdir}/libboost_graph_parallel.so.*" > FILES:${PN}-locale = "${libdir}/libboost_locale.so.*" > FILES:${PN}-mpi = "${libdir}/mpi.so ${libdir}/libboost_mpi*.so.*" > -FILES:boost-serialization = "${libdir}/libboost_serialization*.so.* \ > +FILES:${PN}-serialization = "${libdir}/libboost_serialization*.so.* \ > ${libdir}/libboost_wserialization*.so.*" > -FILES:boost-test = "${libdir}/libboost_prg_exec_monitor*.so.* \ > +FILES:${PN}-test = "${libdir}/libboost_prg_exec_monitor*.so.* \ > ${libdir}/libboost_unit_test_framework*.so.*" > > # -dev last to pick up the remaining stuff > > Depending on which versions you're trying to use, you might need something > like: > > # We don't need old bjam-native to build, current upstream is fine and also > # allows boost-1.82 to build > python() { > raise bb.parse.SkipRecipe('Force upstream bjam-native.') > } > > as a bbappend for the older version so it's skipped. > > On Wed, Aug 16, 2023 at 3:45 PM Nicolas Wirth via > lists.yoctoproject.org > <[email protected]> wrote: > > > > I wasn't aware of BBMASK; that's useful, thank you. > > > > I find it becoming clearer for me. However, I'm wondering how to address > > version conflicts in the following scenario: > > > > GCC 11.2 in the Honister branch > > Boost 1.74 in the Gatesgarth branch > > > > I require the use of both these versions. Although they are both present in > > the meta layer, they exist on separate branches. What would be the solution > > in this case? Would it involve having two clones of the layer on my build > > host? Or perhaps writing my own Boost 1.74 recipe? > > > > Neither option appears to be straightforward to me. Yet, this doesn't seem > > like an uncommon scenario. Others must have encountered the need for > > different recipes from the same layer but belonging to different branches. > > Is there a clear workflow for handling this? > > > > > > > > > -- > Alex Kiernan > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60811): https://lists.yoctoproject.org/g/yocto/message/60811 Mute This Topic: https://lists.yoctoproject.org/mt/100776894/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
