Stefan Teleman writes:
> > shouldn't this be part of the proposal proper? I think at least the
> > detailed library names belong there.
>
> Detailed library names, with API documentation are clearly indicated in the
> ARC
> Materials (documentation). There is a chapter for each and every BOOST
> Library.
... which isn't available on www.opensolaris.org: I get a `Resource Not
Found' error.
> > Besides, is it really necessary to use
> > Major/Minor/Micro in the SONAMEs?
>
> Yes, because this is the software construction mechanism devised by the BOOST
> Developers, and it is the mechanism currently followed by every single
> distribution of BOOST.
That's unfortunate. Even the GNU libstdc++-v3 developers care much more
about binary compatibility, despite their mixed reputation in the past.
> Half of BOOST libraries don't even have a SONAME, because they aren't
> delivered
> as shared library objects, but as header + source files.
I'm obviously not talking about those.
> I'd be interested in learning why we (SMI) should deviate from mainstream.
If the BOOST developers have that unfortunate habit, they should be
educated about better ways (if they exist); I certainly wouldn't request an
OpenSolaris specific fork.
At least, I think those considerations belong into the case
materials/proposal: the reviewers can't know what the BOOST ways are and
why (convenience, laziness, whatever ...).
> > Do the libraries really change incompatibly with every micro release?
>
> Given that BOOST has taken considerable care in designing a construction and
> delivery mechanism which permits non-conflicting coexistence of several
> versions
> of BOOST, this seems to have been done for the purpose of avoiding [
> mitigating
> ] incompatibilities between BOOST releases.
As I said, this might just be their laziness, although I've no positive or
negative evidence (and am no C++ programmer).
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
