[boost] links to non-Boost libraries (Was: MT ...)

From: Dietmar Kuehl (dietmar.kuehl_at_[hidden])
Date: 1999-07-28 10:13:43

Hi,
At 23:36 27.07.99 -0600, Greg Colvin wrote:
[discussion about ACE cut]
>Still, it seems to have everything we need.

Actually, I think the same thing happens with other libraries, eg. Blitz++,
too. Instead of trying to cover everything by the Boost library, it could
be reasonable to point to corresponding libraries and use them in Boost
code. There are only a few restrictions on non-Boost libraries I can think
of:

- We should consistently use one library in Boost code if there are competing
  libraries for the same thing (eg. there is Blitz++ and Pooma, I guess there
  other libraries than ACE which deal with multi-threading, distribtution,
  etc.).
- The interface to the library should have a reasonable interface. If it has
  not, it may be an option to use a Boost provided wrapper.
- The library should be fairly stable and/or provide some versioning such that
  Boost libraries can savely use the library without having to deal too much
  with changes of external libraries.
- If there is a Boost library with equivalent functionality, it would probably
  be preferable to use the Boost one...
- The external library has to have acceptable usage rights, preferable it
  should be free.

That said, I want to clarify that I don't want Boost to become a large
collection of links to more or less arbitrary C++ libraries. Instead, I
envision a small collection of links to selected libraries which can be used
by Boost components to provide portable code for areas where it is currently
impossible to write portable code and maybe some links to great C++ libraries
which could in principle be replicated in Boost but which would basically be
a waste of time (eg. Blitz++). I have mainly areas like multi-threading,
garbage collection, GUI, and networking in mind which are quite platform
specific and for which there are already platform independent libraries. One
of the reasons why such links could be valuable is the fact that there are
a lot of libraries for some of those areas (eg. GUI) and we could evaluate
those and choose one which seems to be especially well suited for our
purpose, stating why we choose this particular library and rejected others,
thereby helping users in their choice of a library.

Although I think that we would be in principle able to implement everything
we want, I doubt that we would be able to do so in a timely fashion. Thus,
lets use the work of others to boost the whole community! Of course, selection
of an appropriate library is also work which would probably not lead to a
single library favoured by everybody. ... but then we could use a poll to
select amoung the favoured libraries.

Dietmar