[cfe-dev] AST processing toolbox

[AlisdairM(public)]

> -----Original Message-----
> From: Ted Kremenek [mailto:kremenek at apple.com]
> Sent: 12 June 2009 20:38
> To: AlisdairM (public)
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] AST processing toolbox
> 
> On Jun 12, 2009, at 5:28 AM, AlisdairM(public) wrote:
> 
> >> 1. I use boost, in particular boost::bind and boost::function (that
> >> is,
> >> header only for the moment). Unless there is something similiar in
> >> llvm
> >> (which I didn't found yet), I won't like to change this. However
> this
> >> would add dependencies to boost and I don't know the opinions of the
> >> main developers regarding this issue.
> >
> > I'm too new around here to know Clang policy wrt the C++ standard
> > library,
> > but I notice that both the libraries you mention are part of TR1, so
> > it
> > might be better to use the TR1 names for those components instead?
> 
> In general, we would prefer to not suck in pieces of external
> libraries unless they significantly add value to the development of
> LLVM/Clang.  This is both for portability as well as maintainability.
> FWIW, the discussion on adding pieces of Boost to LLVM/Clang has been
> discussed before, and unless there is a compelling need to pull in a
> specific piece of Boost it is something we won't do for the reasons
> I've given.  This has nothing to do with Boost per se; it's really
> about keeping the codebase simple and free of unneeded, extraneous
> dependencies on other libraries.  Please keep in mind that we've
> managed to build an entire working compiler without these libraries.

My thought here was not so much to adopt (elements of) Boost, but of
std::tr1.  Most modern C++ compilers ship with TR1, and Boost provide
a freely available 3rd party solution for older compilers the vendor
no longer supports.  In principle though, this is merely another part
of your standard library now, lurking in namespace tr1 ahead of
formal standardisation in C++0x.

Now that might still be more than we want to depend on - as you say
we have come this far without it.  I believe it offers significant
value though, if it is something we can assume from a 'standard'
C++ installation.

AlisdairM