Date: 2001-04-19 07:07:37
The initial release of the Boost.Compatibility library
is now completed. I just checked in the directory
The header files in this directory facilitate the use of
Boost on Silicon Graphics workstations running IRIX,
and Compaq Alpha workstations running both Linux and
Tru64 Unix. For details see
--- In boost_at_y..., rwgk_at_m... wrote:
> I just checked in a new directory root/libs/compatibility
> with an index.html file and a Python script. I have not yet
> checked in the root/boost/compatibility directory.
> From the new index.html:
> The header files created by this script reside in the
> directory root/boost/compatibility/cpp_c_headers.
> To use the header files, add this directory to the
> include file search path. For example:
> cxx -I/usr/local/boost/boost/compatibility/cpp_c_headers ...
> What I am not sure about is the "boost/boost" part of the
> pathname. For the particular case of the cpp_c_headers directory,
> it is of no benefit that it resides in root/boost. This is,
> it seems unlikely to me that one would ever want to:
> #include <boost/compatibility/cpp_c_headers/cstdio>
> Therefore root/compatibility would almost seem to be a more
> logical place for the cpp_c_headers directory.
> Then again, in the future there might be other compatibility
> header files that are better placed in root/boost/compatibility.
> Before creating a subdirectory that is very difficult to
> remove again, I would like to know what other people think
> about this.
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > Perhaps segregate the material in a Compatibility Library.
> > location root/boost/compatibility/ for headers and
> > root/libs/compatibility/... for everything else.
> > Say up front in the index.html file that we hope these libraries
> can be
> > removed at some time in the future. But that until standard
> > suppliers become more standard conforming, we supply workarounds
> > allow Boost to be used on otherwise non-conforming platforms.
> > --Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk