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.
