On Wed, Dec 3, 2014 at 1:05 PM, Jason L Tibbitts III <tibbs@math.uh.edu> wrote:

>>>>> "DJ" == Dave Johansen <davejohansen@gmail.com> writes:

DJ> I'm working on that but it sounds like that's going to take a bit of
DJ> work and probably won't be included until a future version of clang
DJ> any ways.

Well, the problem is that the software you're packaging essentially
wants to use the internal components of clang. Are those intended for
consumption by other programs? It would seem not as they aren't shared
libs. Is there some sort of API guarantee? I would assume not, but
you're going to have to rebuild your package every time clang changes.
What will you do if it doesn't build because the API changes
incompatibly?

As far as if the used components are "private", I'm not familiar enough with the clang code to know for sure. There's some discussion going on in the iwyu mailing list ( https://groups.google.com/forum/#!msg/include-what-you-use/JmhHHmMhxXs/y7fnaiO01vcJ ) about moving iwyu to use to clang's tooling interface ( http://clang.llvm.org/docs/Tooling.html ), but that probably won't happen any time soon. Also, my understanding is that won't fully fix this problem and actually just means that iwyu would have to be packaged as part of LLVM (or at least that's how all of the existing "tools" work).

As far as the API goes, the LLVM/clang API is notorious for being dynamic and requiring users to "keep up". My strategy is to rely on upstream to make those sorts of API changes and I will just do the packaging to make iwyu available on Fedora/RHEL.