[cfe-dev] AST processing toolbox

[Ted Kremenek]

On Jun 12, 2009, at 1:03 PM, AlisdairM(public) wrote:

>>> etter 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.

I think even depending on TR1 might be too high (at least at this  
point), as we want Clang to compile on as many platforms as possible  
that have a "reasonable" C++ compiler. I could be wrong, but I don't  
think we want people to have to install Boost in order to compile  
Clang if they don't have an available TR1 solution.

Another possibility, when Clang eventually has the capability to  
bootstrap itself, libraries not part of the core compiler could be  
compiled using a bootstrapped Clang and use whatever C++ features  
Clang supports.

That said, there is an ongoing discussion on which C++ features we  
should actually use in LLVM/Clang.  At the end of the day, not  
everyone who contributes to LLVM/Clang is a C++ guru, and using  
esoteric C++ features may actually be more of a detriment than a  
blessing as it may scare off potential contributors.  So when we look  
at whether or not to pull in library X or language feature Y into the  
code base, we need to consider the tradeoffs both in terms of  
technical benefits (which may be marginal) versus (a) the  
approachability and readability of the code base and (b) the  
portability of the code base.  We aren't luddites, however, as we do  
indeed use some of the more "specialized" features of C++ in LLVM/ 
Clang, but they are buried deep in the code and help provide  
fundamental infrastructure instead of being used as part of the basic  
APIs.