Subject: [boost] questions regarding visibility and b2
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-27 17:29:59
I've got a few questions about the "visibility" changes for boost.
My understanding is that "visibility" for gcc and clang are "sort of the
same thing" as dll import and export are for windows.
Now we've made "visibility" the "default".
But this seems kind of weird. This has been made a b2 feature. In
order to run tests, this feature is applied to the b2 command line.
What's weird is that it's applied to the tests/executables and
propogated down to libraries which are built. I actually don't know
what "visibility" means in the context of building and executable. If I
want to use visibility=global then on the library build, it needs to be
applied to everything. It's very weird and doesn't seem in line with
the windows solution.
Heretofore, I've applied visibility to the library build "by hand" by
adding the appropriate command line switches to the right places. I'm
aware that this is not the b2 way. But the b2 way doesn't seem to make
sense to me. On the bright side, changing default visibility didn't
seem to have any effect on the serialization library other than on one
test. Unfortunately, turning this confused a pending issue and made it
even more contentious than it already is/was.
FWIW - this is not so much the fault of b2 or anyone in particular. The
use of DLLS/shared libraries is the triumph of development over design
by vendors, each of whom do their own thing and have never been able to
get it together. By now this has created enough technical debt that it
will take years to straighten out if people actually start to address
it, which no one seems interest in doing.
Anyway, the b2 approach is pretty confusing and probably wrong. I'm
also guessing that, as one would predict, a change like this is going to
provoke subtle failures in lots of small corners which will take quite a
while to discover. I'm not sure how to address this.
Robert Ramey