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

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