On Wed, Dec 3, 2014 at 1:05 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu>
>>>>> "DJ" == Dave Johansen
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
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 (
) about moving iwyu to use to clang's tooling interface (
), 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.