Boost: why "--layout==tagged"?

[Ryan Schmidt]

On Jan 17, 2019, at 14:17, Michael Dickens wrote:

> I've been trying to get Boost 1.69.0 working, without much luck yet because the default installed library names as installed by MacPorts are changed from "libboost_COMP-mt.dylib" to "libboost_COMP-mt-ARCH.dylib", where "COMP" is the component name (e.g., "system", "thread") and "ARCH" is the abbreviated architecture (e.g., "x64" for Intel x86 64-bit, "p32" for PPC 32-bit).

I have not looked into it, but that certainly sounds like a ridiculous change that we would want to revert in MacPorts, if we stick with the tagged configuration.


> None of the build systems that I've checked (cmake and autotools) recognizes this style of library name. I think I can coerce CMake into working, but it's a bit of a hack & may not work work universally. I'd guess I can do the same for other build systems, but each is unique & hence I'd rather get rid of the ARCH part of the library names. Which got me wondering about why the whole "mt" part too.
> 
> After some sleuthing, I find that one reason for the library name change is that in the Boost Portfile we're using build.args of "--layout=tagged" rather than the default of "--layout=system". When using the latter, I get just the basic library names: "libboost_COMP.dylib", which to me actually makes the most sense: the goal of "tagged" is to allow simultaneous / parallel installation of multiple Boost libraries: single ("") & multi-threaded "-mt"; different ARCH ("-x64", "-p32" etc); different compilers and compiler versions ("clang10", "gcc8", etc)... you get the idea.
> 
> For all practical purposes, we in MacPorts-land just install Boost ... one version, and that's it. We don't need all of the tagged naming for multiple versions installed -- at least not in my experience or opinion.
> 
> The commit that moves from "system" to "tagged" goes -way- back: < https://github.com/macports/macports-ports/commit/2dbce9b6303f26dc055c53d3302f8c158c025294 > ... by Anthony Ramine committed on Jun 19, 2009.
> 
> So .... wondering what folks think about moving back to "system" here and just the basic library names. I'm all for it; if you're not, I'd wonder why not? - MLD

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.