On Mon, Aug 29, 2016 at 12:16 PM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: > On Mon, Aug 29, 2016 at 10:00 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> I think this is #4: >> >>> 4) #1, with cmake smarts to let you choose the submodule or installed >>> boost (and possibly autoselect system boost if it's new enough). > > Oh cool, sorry I didn't understand that :) Yes, that sounds good. > >> The goal should be to eventually drop the submodule as supported distros >> are brought up to date. I suspect, though, that we'll find other shiny >> new features we'll want to start using so this may never happen... > > If we're still finding features from the latest boost that we want > years from now, then I'm ok with that. It means that someone's keeping > the bundled library up-to-date, the project is still getting value > from the bundled library, and the asset-vs-liability scale is properly > balanced IMHO. > Boost is one of those projects where there's not too much value in using the distro package. For starters, Boost is so template heavy that the vast majority of code ends up getting compiled with the actual executable. It also makes no guarantees about forwards / backwards compatibility new version of boost requires a rebuild of all the apps dependent on it. So all the normal distro arguments about one library shared across many packages and security updates becomes void. Because of the lack of forwards/backwards compatibility guarantees it's also hard to build against against distro versions because every distro (and then FreeBSD) all end up using different versions. So I would argue that it's hard to certify correctness unless one version of Ceph is always using one version of boost. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
