LLVM currently uses one boost template "boost::is_class" in the command line
argument handling stuff.

It would be really nice to get rid of this, because then we could remove the
include/boost directory, and not have it clutter up the 'make install' process.

I'm not sure what a good way to get this is, other than implementing our own
'is_class' trait template.  This shouldn't be hard, someone just needs to do it.

-Chris

Well, here's something I CAN do :) .. Assigning to me.

Cool, thanks Reid!

At worst, we could just include the boost is_class template and all of its
dependencies in an llvm::is_class template, but obviously something nicer would
be  better.

What the CommandLine library _really_ wants to know is if it's safe to derive
from some 'T' (ie, it's a class).  If so, cl::opt and friends derive from the
class, allowing (for example) cl::opt<std::string> to behave _exactly_ like the
std::string class, including having all of the methods std::string has.

Anyway, if you have any questions, let me know,

-Chris

I have it down to about 10 lines of code with zero boost stuff. I'm trying to
recompile but the cvs server isn't letting me update right now :(

I looked at fidgeting with opt_storage but decided it would be easier to provide
a simple solution for is_class. Might be useful elsewhere too.

The only question I have is about compiler compatibility with my solution. I'm
right on the edge of what GCC 3.3 supports. I have two template functions that
are used in the implementation. If I put them inside is_class<T> then it won't
compile but if they're outside, it compiles. Go figure!  All that happens to
these functions is that sizeof() is taken on a call to them.  Anyway, if we need
to support GCC before 3.3 or other compilers, we'll need to test my solution on
those compilers. If the compiler doesn't work on this solution, its broken
because the syntax and semantics are standards conforming.  Nice thing about
standards is there's so many to choose from and they change every year. :)

Reid

> I have it down to about 10 lines of code with zero boost stuff.

GREAT, that is better than I expected!  :)

> The only question I have is about compiler compatibility with my solution. I'm
> right on the edge of what GCC 3.3 supports.

Ok, so here's my general idea of what we should support.  GCC 3.0 is clearly
broken, 2.95 is completely hopeless.  GCC 3.1/3.2 (which are effectively
identical) are still widely used and we should be compatible with them if
possible.  I use 3.3 daily, so if you want me to test something, I certainly
can.  Compatibility with 3.4 is also critical, as that is what LLVM currently
uses. :)

So overall, I would prefer the solution to work with GCC 3.1/3.2...  does this
seem reasonable/possible?

-Chris

Created an attachment (id=85) [details]
A patch to remove use of boost from LLVM

Note: This patch depends on the next attachment. It changes the inclusion of
boost header files to use include/Support/TypeTraits.h instead. The next
attachment includes TypeTraits.h

Created an attachment (id=86) [details]
Implements the is_class template

This file contains just template<typename T> struct is_class. This is a plug
compatible replacement for ::boost::type_traits::is_class<T>.

The patches, if applied to latest  CVS, compiles fine. I haven't actually run
anything to see if it works, but I don't expect problems. I tested is_class with
the test program embedded in the TypeTraits.h header file (second attachment).

Regarding compiler support. I found an old 3.1.1 compiler on my system and
tested with that. It worked fine. I don't know about 3.2.X but I can't imagine
the feature it depends on disappearing in 3.2 and then reappearing in 3.3.  So,
I think we are okay on compiler support. If you want to be pedantic about it,
you'll have to come up with a 3.2 compiler and test it. Note that you can test
the functionality just by compiling TypeTraits.h with -DTEST_TYPE_TRAITS on the
compilation line. When you're satisfied that all is well, you can remove that
test program from TypeTraits.h

The code works great, and, as I'm sure you saw, has now been applied to CVS.  

BTW, if 3.1 works, I'm sure that 3.2 will work also, the only difference is an
ABI change.

Thanks for tackling this Reid!

-Chris

No problem. I'm glad to help where I can. If you have more of these
self-contained cleanup tasks, file bugs for them and I'll pick them up where I can.