From: Love, Steve (Steve.Love_at_[hidden])
Date: 2000-02-24 06:17:18
> Why not insist for Windows on a Cygwin installation? Then
> we'll have an
> environment, that supports the procedure described above in
> the same way for
> Windows as for Unix. I've built meanwhile enough Unix tools
> successfully for
> Windows that were prepared for Cygwin. This would minimize
> the maintenance
> effort and the boost may just provide a link to Cygwin to get
> an installation of
> the tools.
This would preclude the use of the library in say Borland Builder. Also, cygwin
is 13+ MB, which is a bit much to insist upon, IMO. And what about BEOS? OS/2?
Given the basic expertise required to understand much of what the BOOST libs do
(i.e. somewhere over my head ;)), is it not that unreasonable to be able to
expect the programmer to be able to download and configure/build BOOST for
their chosen platform?
AFAICS the library is predominantly STD C++ so any platform specifics are the
delta between the standard and what they can achieve, which is probably
documented. Such things as template friends, std namespace for C identifiers
and so on.
Any non-standard items (i.e. platform specific modules) have the question
unasked anyhow. They are presumably already configured for their platform.
Beman Dawes wrote:
Each sub-directory represents a platform, and holds an index.html
(the modern version of readme.txt), plus whatever scripts, batch
files, or magic is required to build a boost binary library for that
platform. The scripts don't have the source files wired into them,
they just build whatever is in libs/src. The output goes into the
current directory so multiple builds can coexist.
This seems reasonable also, at the expense of extra effort for the maintainers.
Some kind of compromise between this and the above (like Boris Fomichev's
STLport header, which you edit according to what you support) seems the way.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk