llvm dev - Jul 2007 - [LLVMdev] Boost Support

I've been doing some experiments with the Boost Graph Library (BGL) and 
interfacing to llvm's GraphWriter system.  I'm using GBL for some custom
work and needed a way to hook BGL's write_graphviz into GraphWriter to use
the existing display infrastructure.

To do this I added a HAVE_BOOST configure item and #ifdef'd the Boost 
support code in GraphWriter.

Is this useful to anyone else?  Is it something desireable to contribute back?

This also opens a larger question about whether making use of Boost components
is a reasonable thing to do.  We already have some Boost type traits in the
llvm tree.  Why not just use the real thing (or use tr1 type traits)?

Certainly adding a dependency on Boost is a big change and deserves lots of
scrutiny.  But there is a ton of good stuff in there that is really useful for 
compiler work.  In my own work I've made use of tuples, BGL, MPL (very 
limited), bind (also in tr1), optional, io_state_savers, iterators, 
static_assert, and will probably soon be using multi_index to improve 
algorithmic complexity.

A smaller step would be to accept tr1 things.

I'm not making a big push for Boost or tr1, just raising the question to
start a discussion about the long-term direction of the project.

                                                -Dave

On Wed, 4 Jul 2007, David A. Greene wrote:
> I've been doing some experiments with the Boost Graph Library (BGL) and
> interfacing to llvm's GraphWriter system.  I'm using GBL for some
custom
> work and needed a way to hook BGL's write_graphviz into GraphWriter to 
> use the existing display infrastructure.
ok
> To do this I added a HAVE_BOOST configure item and #ifdef'd the Boost
> support code in GraphWriter.
>
> Is this useful to anyone else?  Is it something desireable to contribute
back?
I'd prefer not to do this.  Boost contains a lot of powerful stuff, but 
its power comes at a significant compile-time cost.  Further, LLVM used to 
use boost for various small things, and it was always a problem keeping in 
sync with various versions of boost.

In order to pull in boost, it would have to give us *significant* new 
functionality that we can't reasonably implement another way.
> This also opens a larger question about whether making use of Boost
components
> is a reasonable thing to do.  We already have some Boost type traits in the
> llvm tree.  Why not just use the real thing (or use tr1 type traits)?
Portability, dependency on another third-party library, compile-time, 
bulk, etc.
> A smaller step would be to accept tr1 things.
Unfortunately, tr1 isn't widely available yet.  Relying on it would make 
LLVM less portable, no?

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/