OK yes we -offer- multiple versions, but only one version can be installed at a time right now. And, when using "--layout==tagged" I'd bet that the resulting ABI name changes for each installed variant, which means that all ports that depend on Boost would have to be rebuilt when switching between variants.
I firmly believe that the vast vast majority of folks pick their Boost variant and stick with it through the lifetime of that Boost version if not the whole MacPorts install. The number of folks who actively switch between Boost variants is IMHO very very small. One can always do "port installed boost and active" to determine which variants were selected for the specific Boost install. Hence, if I'm otherwise correct about folks' usage of Boost, then the actual ABI name makes no real difference: for linking purposes, for reading purposes, for any other purposes. This is my argument for moving from "tagged" back to "system": it might inconvenience a very small number of folks, but at the same time it will make Boost easier to maintain for those of us trying to do so. - MLD ps> Subports could be made to work instead of variants -- and I'd love to see those for Boost::Python versions for example to be able to install whichever versions we want at the same time since the API is the same but the ABI names will be different starting with Boost 1.68.0 (or maybe even 1.67.0) -- but I'd still like the "default" Boost install to be "system" naming. I don't have time to even do the Boost::Python subports right now & likely won't for months, let along all of Boost! On Fri, Feb 1, 2019, at 1:11 PM, Ryan Schmidt wrote: > We *do* offer multiple versions, four in fact: single-threaded static, > single-threaded dynamic, multithreaded static, and multithreaded > dynamic. > > We have variants with (ill-advised) names no_static and no_single to > disable some of those. We enable both of those variants by default to > speed up building; the decision to do that predates the existence of > precompiled port binaries in MacPorts 2 which make the speed issue > irrelevant for those users who get binaries. > > Really, we should have moved the multithreaded and single-threaded > versions to separate subports. > > If we want to delete the ability of MacPorts to offer the single- > threaded version, we can certainly do that. I don't know what the > consequence of doing that would be. I don't know if anybody is currently > relying on the single-threaded versions. If they are, silently > "upgrading" them to the multithreaded versions as you propose will > certainly break their use case. > > If we do make the change, of course we have to revbump everything that > links with boost. There are also a zillion places where the "-mt" suffix > had to be passed to build systems, either via arguments in the Portfile > or with patchfiles; all those instances would have to be found and > changed.
