BOOST C++ Framework [PSARC/2008/752]
All, As per the PSARC business meeting I am closing this case as approved since the discussion has concluded. Thanks, John On Wed, 2008-12-10 at 11:21, Stefan Teleman wrote: > Rainer Orth wrote: > > Garrett D'Amore writes: > > > >> If I understand correctly, Stefan's response is that minor/micro > >> versions are required because there *can* be incompatible changes in the > >> Boost libraries from upstream. That is to say, Boost doesn't guarantee > >> binary compatibility, but instead requires developers to code to a > >> specific release. > > > > That's what I now found in the BOOST FAQ at > > > > http://www.boost.org/users/faq.html > > > > (How can the Boost libraries be used successfully for important projects?) > > Some postings on their mailing lists indicate that their track record for > > compatiblity isn't particularly good, even silently breaking compatibility > > in micro releases (which seem to be rare, though). > > > >> While this may seem unfortunate, its the way Boost developers work, I > >> guess. Its not particularly worse, IMO, than the other problems > >> inherent in using C++ when you care about compatibility. > > > > Seems so, yes. > > This happens mainly because BOOST is, first and foremost, a language research > project. The intent is to discover and provide implementations for new > language > idioms and techniques, and as such, maintaining compatibility takes a second > seat. The consistency and compatibility aspect is addressed by including > BOOST > components in the Language Standard, at which point these components acquire > the > expected Interface Stability Classification commitment. > > --Stefan > > -- > Stefan Teleman > Sun Microsystems, Inc. > Stefan.Teleman at Sun.COM >
BOOST C++ Framework [PSARC/2008/752]
Garrett D'Amore writes: > If I understand correctly, Stefan's response is that minor/micro > versions are required because there *can* be incompatible changes in the > Boost libraries from upstream. That is to say, Boost doesn't guarantee > binary compatibility, but instead requires developers to code to a > specific release. That's what I now found in the BOOST FAQ at http://www.boost.org/users/faq.html (How can the Boost libraries be used successfully for important projects?) Some postings on their mailing lists indicate that their track record for compatiblity isn't particularly good, even silently breaking compatibility in micro releases (which seem to be rare, though). > While this may seem unfortunate, its the way Boost developers work, I > guess. Its not particularly worse, IMO, than the other problems > inherent in using C++ when you care about compatibility. Seems so, yes. > It certainly doesn't seem reasonable to expect the project team to > deviate significantly from the release strategy used by the upstream source. No, as I already said I wouldn't require them to do so. It would only have been very helpful to document those issues more clearly in the case materials, because the question inevitably comes up and could have been answered up front. > Rainer, are you satisfied with Stefan's response? I think so, yes. Rainer - Rainer Orth, Faculty of Technology, Bielefeld University
BOOST C++ Framework [PSARC/2008/752]
Stefan Teleman writes: > Stefan Teleman wrote: > > > 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. > > More specifically, this: > > http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Removed which is a single `Library' removed 5 minor releases back, no incompatibility in every micro release. Rainer - Rainer Orth, Faculty of Technology, Bielefeld University
BOOST C++ Framework [PSARC/2008/752]
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
BOOST C++ Framework [PSARC/2008/752]
John Fischer writes: > This project proposes to include the BOOST C++ Framework within > a Minor release of Solaris. BOOST allows for Parallel versions > to be installed on a system. This project will install BOOST > into /usr/include/boost/.. and /usr/lib > with the library SONAME corresponding to the Major/Minor/Micro > name scheme. BOOST depends upon the previous Standard C++ Library > provided by the platform specific C++ Compliation and Run-Time > Environment. shouldn't this be part of the proposal proper? I think at least the detailed library names belong there. Besides, is it really necessary to use Major/Minor/Micro in the SONAMEs? Do the libraries really change incompatibly with every micro release? This way, one has to accumulate many library versions over time. Same question for the headers. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
BOOST C++ Framework [PSARC/2008/752]
Rainer Orth wrote: > Garrett D'Amore writes: > >> If I understand correctly, Stefan's response is that minor/micro >> versions are required because there *can* be incompatible changes in the >> Boost libraries from upstream. That is to say, Boost doesn't guarantee >> binary compatibility, but instead requires developers to code to a >> specific release. > > That's what I now found in the BOOST FAQ at > > http://www.boost.org/users/faq.html > > (How can the Boost libraries be used successfully for important projects?) > Some postings on their mailing lists indicate that their track record for > compatiblity isn't particularly good, even silently breaking compatibility > in micro releases (which seem to be rare, though). > >> While this may seem unfortunate, its the way Boost developers work, I >> guess. Its not particularly worse, IMO, than the other problems >> inherent in using C++ when you care about compatibility. > > Seems so, yes. This happens mainly because BOOST is, first and foremost, a language research project. The intent is to discover and provide implementations for new language idioms and techniques, and as such, maintaining compatibility takes a second seat. The consistency and compatibility aspect is addressed by including BOOST components in the Language Standard, at which point these components acquire the expected Interface Stability Classification commitment. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
BOOST C++ Framework [PSARC/2008/752]
Stefan Teleman wrote: > 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. More specifically, this: http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Removed --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
BOOST C++ Framework [PSARC/2008/752]
Rainer Orth wrote: > John Fischer writes: > >> This project proposes to include the BOOST C++ Framework within >> a Minor release of Solaris. BOOST allows for Parallel versions >> to be installed on a system. This project will install BOOST >> into /usr/include/boost/.. and /usr/lib >> with the library SONAME corresponding to the Major/Minor/Micro >> name scheme. BOOST depends upon the previous Standard C++ Library >> provided by the platform specific C++ Compliation and Run-Time >> Environment. > > 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. > 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. 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'd be interested in learning why we (SMI) should deviate from mainstream. > 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. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
BOOST C++ Framework [PSARC/2008/752]
The timeout on this was extended to Friday Dec. 12. If I understand correctly, Stefan's response is that minor/micro versions are required because there *can* be incompatible changes in the Boost libraries from upstream. That is to say, Boost doesn't guarantee binary compatibility, but instead requires developers to code to a specific release. While this may seem unfortunate, its the way Boost developers work, I guess. Its not particularly worse, IMO, than the other problems inherent in using C++ when you care about compatibility. It certainly doesn't seem reasonable to expect the project team to deviate significantly from the release strategy used by the upstream source. Rainer, are you satisfied with Stefan's response? -- Garrett On 12/10/08 10:26, Stefan Teleman wrote: > > > Stefan Teleman wrote: > >> 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. > > More specifically, this: > > http://www.boost.org/doc/libs/1_37_0/libs/libraries.htm#Removed > > --Stefan >
BOOST C++ Framework [PSARC/2008/752]
+1 on this case. I haven't read all the Boost documentation, but with its Uncommitted binding, and reliance upon earlier precedent, combined with the fact that the library is a popular C++ building block, I think it would be good for Solaris to have to this integrated. -- Garrett On 12/04/08 11:45, Mark Martin wrote: > John Fischer wrote: >> PSARC, >> >> I am sponsoring this case for Stefan Teleman from the SWF group >> in Menlo Park. The case directory contains this proposal and the >> BOOST documentation which can be accessed via: >> >> http://sac.eng/Archives/CaseLog/arc/PSARC/2008/752/materials/boost-doc-1.37.0/ >> >> >> > Theoretically, > http://www.opensolaris.org/os/community/arc/caselog/2008/752/materials/boost-doc-1.37.0/ > > > once things synchronize (case dir not yet available at 19:45 UTC) >
BOOST C++ Framework [PSARC/2008/752]
John Fischer wrote: > PSARC, > > I am sponsoring this case for Stefan Teleman from the SWF group > in Menlo Park. The case directory contains this proposal and > the BOOST documentation which can be accessed via: > > http://sac.eng/Archives/CaseLog/arc/PSARC/2008/752/materials/boost-doc-1.37.0/ > Theoretically, http://www.opensolaris.org/os/community/arc/caselog/2008/752/materials/boost-doc-1.37.0/ once things synchronize (case dir not yet available at 19:45 UTC)
BOOST C++ Framework [PSARC/2008/752]
PSARC,
I am sponsoring this case for Stefan Teleman from the SWF group
in Menlo Park. The case directory contains this proposal and
the BOOST documentation which can be accessed via:
http://sac.eng/Archives/CaseLog/arc/PSARC/2008/752/materials/boost-doc-1.37.0/
I have set the timeout for Thursday, December 11th, 2008.
This project proposes to include the BOOST C++ Framework within
a Minor release of Solaris. BOOST allows for Parallel versions
to be installed on a system. This project will install BOOST
into /usr/include/boost/.. and /usr/lib
with the library SONAME corresponding to the Major/Minor/Micro
name scheme. BOOST depends upon the previous Standard C++ Library
provided by the platform specific C++ Compliation and Run-Time
Environment.
Thanks,
John
-- next part --
Including the BOOST C++ Framework with Solaris
Stefan Teleman
03 December 2008
1. Summary and motivation
The BOOST C++ Framework is a Collection of Open Source,
portable C++ source and object libraries. BOOST is designed
with concern for portability and Standard C++ compatibility
first and foremost. [0]
BOOST seeks to establish existing practice precedent, and to
provide reference implementations suitable for eventual
standardization.
To this effect, BOOST's Home Page states: "Ten Boost libraries are
already included in the C++ Standards Committee's Library Technical
Report [TR1] as a step toward becoming part of a future C++ Standard.
More Boost libraries are proposed for the upcoming TR2." [1] [2]
This FastTrack proposes the integration of the latest Stable BOOST
Release, Version 1.37.0.
This Case seeks Micro/Patch release binding.
2. Technical issues
2.1.Key Objects
The complete list of all the Objects and Interfaces provided by
BOOST is very large. For the purposes of this ARC Case,
and in order to maintain brevity of this document, a full and
complete document set detailing all the Intefaces and Objects
delivered by BOOST will be provided as an Addendum in the ARC
Case Materials. This documentation is provided by the BOOST Project.
BOOST delivers both source code and shared library objects.
This mixed object delivery mechanism is consistent with the design
of the C++ Programming Language. [3]
A high-level overview of a canonical BOOST distribution
outlines the following directory structure:
[$BOOST]/include/
[$BOOST]/include/boost/
[$BOOST]/include/boost/..
[$BOOST]/lib/
[$BOOST]/lib/${MACH64}
For the purposes of this Document, [$BOOST] revers to the root
directory installation of a particular BOOST release.
This Integration will deliver BOOST objects under /usr, following
the recommendations set forth by PSARC/2005/185. [4]
BOOST's construction and installation mechanisms allow for the
coexistence of several BOOST versions by default. This facility
is provided via two different mechanisms:
- For header files, each BOOST release installs its
header files under a versioned subdirectory.
- For shared libraries, the library name, and its
binding SONAME hardcode the corresponding Major/Minor/Micro
triad.
Further details about facilitating the correct and complete BOOST
object discovery mechanisms are discussed below.
BOOST delivers no executables.
2.2.C++ ABI Considerations
BOOST is dependent on the Standard C++ Library provided by the
platform specific C++ Compliation and Run-Time Environment.
As such, all the C++ ABI considerations, and the precedent
established by PSARC/2008/549 apply to this BOOST Integration.
[5]
2.3.Internationalization
BOOST provides full support for internationalization and
localization through Native Language Support and multibyte
[ wchar_t ] character support, if such support is provided
by the platform specific Standard C++ Library. In addition,
BOOST imports Interfaces from International Components
for Unicode [ ICU ]. [6] Details about external Interfaces
imported by BOOST are further discussed below. Implementation
detail particulars for Internationalization and Localization
are purposely delegated to the application importing BOOST
interfaces, with the presumption that BOOST maintains full
compatibility with the Standard C++ Library provided by the
C++ Run-Time Environment.
2.4.Documentation
BOOST provides a full documentation set in HTML support. This
documentation set will be included with this BOOST Integration.
3. Interfaces
