I have a project which uses gtkmm and I thought I'd try to test
CEDET with it (that is, I didn't want to create a persistent ede
project or anything but instead set things up on the fly for just
one session). As expected, CEDET couldn't automatically find gtkmm
include files such as the following one:
That file is located at /usr/include/gtkmm-2.4/gtkmm/main.h so I
figured I'd add /usr/include/gtkmm-2.4 as a system include path
using semantic-add-system-include. I did that and the include
summary indicates the path was added and main.h is no longer an
unknown include but unparsed. Yet the #include <gtkmm/main.h> line
is marked red and if I use Unknown Include menu's What Is This?
selection, it says the file has been marked "Unknown".
I try M-x bovinate RET but it has no effect. I can't think of
anything else that would turn it yellow except reopen the file. I
do that and it's now yellow. Unparsed Include explains that it is
unparsed (but doesn't explain why) and instructs that I can parse
it or all the includes. I choose to parse all the includes. CEDET
parses gtkmm includes for a while, Emacs' memory consumption rises
to 106/40MB (virt/res; this is a 64bit system) and finally after it
starts parsing LL/stock.h (the file is actually
/usr/include/gtkmm-2.4/gtkmm/stock.h) and reaches 5% point it gets
stuck, eating all CPU it can.
I interrupt it with C-g. I open file where gtkmm/stock.h is
included and observe that the include line is not marked with any
color so apparently it believes it got parsed even though parsing
was interrupted. Include summary for stock.h says "stock.h : 0
tags, 0 are includes."
I let Emacs idle for a while and apparently some timer hits and
makes CEDET parse even more include files. This time parsing gets
stuck at LL/confname.h which is apparently
/usr/include/bits/confname.h, included indirectly somewhere. I
interrupt with C-g again.
I'm using Emacs 22.1.1 and CEDET from CVS as of
2009-03-02T23:31+0000. gtkmm include files are from Ubuntu
libgtkmm-2.4-dev package version
1:2.12.5-2. /usr/include/bits/confname.h is from libc6-dev version
Given those packages, I can reproduce the stock.h parsing problem
with this code (probably with just #include <gtkmm/stock.h> too but
I didn't try that):
int main(int argc, char** argv)