AW: KDevelop ctags symbol browsing on external dependencies (solution)

[Roland Krause]

Markus,
thank you very much for your email. You have pretty much summarized the
problem with ctags and outlined its limits. 


--- Markus Kuehni <markus.kuehni at trilab.ch> wrote:
> You should still somehow scan for actual #includes in the project and
> *not*
> only offer headers well-known in advance.

Yes, one could do a combination of a few standard directories, e.g.
/usr/include, $QTDIR/include, $KDEDIR/include etc. and additionally do
the .dep scan for more directories. Additionally the user should be
allowed to add directories by hand. The tags file for these directories
can be generated "once in a while". 

> I think KDevelop has reached a level that qualifies it for much more
> than
> "just" plain-vanilla KDE apps. I intend to use it for a wxWindows
> project,
> for instance, with its own set of headers.

Good. I hope this works out well for you. 

> Also you'd have to be careful not to include too much. This approach
> would
> either have to scan for actual #includes in the project too or let
> the user
> configure (tedious!) the tags dbs to be considered. Otherwise you'd
> get tons
> of unrelated symbols.
> 
> ctags already has the "shortcoming" of not considering conditional
> compilation (#ifdefs) and thus catalogueing symbols that are not
> active in
> the current project configuration. Indiscriminately adding headers
> would
> "pollute" the symbol space further.

Yes, here is where we do find the limitations of ctags.

> > This tags file doesnt have to be regenerated and should be stored
> in a
> > central location.
> 
> You're right, that's a much cleaner approach in theory.
> 
> But you'll open a can of worms there. You'll either have write access
> to the
> #include directories or build a mirror repository which, again,
> should be
> protected from user tamper. So you'd have to /su/ in order to
> (re)generate
> the tags. You'd have problems keeping up to date with installed
> headers.

Hmm, I was more thinking of something like $KDEDIR/share/apps/kdevelop,
but you maybe right here. It can very well be stored in the users
directory.

> 
> A deamon for that pupose is the only valid solution, I think, and in
> my
> opinion that's "mit Kanonen auf Tauben geschossen".

There is a sourceforge project with a similar approach. I agree with
you, that doesnt make sense to me either. 

> 
> The KDevelop project itself (which I consider a "big" example) has a
> 0.8Mbyte tags file normally and a 2.3Mbyte one with the patch. This
> compares
> against 43.5Mbytes of *.o files which roughly is 5.3%. I think that's
> acceptable.

Yes, it sure is. 

> 
> I think the /concept/ of my patch is the right thing to do. But not
> the
> implementation.

The current ctags implementation is still suboptimal, my goal is to
make it into a kpart later, add the ctags commandline configuration
dialog and reroute the output into one of the tabbed output windows. 

> 
> Using shell command line expansion is always incredibly effortless
> but at
> the same time it's still somehow a hack, because it heavily depends
> on OS
> facilities. Who knows when KDevelop will be ported to Windows ;-) ?

Windows? what is Windows again? :-) 
> 
> In the interim, one could add a HAS_EGREP autoconf macro and
> conditionally-compile the patch in. Or a U*X-guru could probably
> rewrite the
> commands using awk, which I believe is universally available.

I'll put the patch in. 

About your note. You are again correct. But if you wanted to go that
far, you might as well consider using gcc's XML output which will give
you the equivalent of MSVC's browse database. 
Then all you need to do is "tag index" that database for fast searching
and you have all information you ever need, including a highly accurate
class tree and a basis for a robust code completion algorithm 

Roland

> 
> *NOTE*
> 
> Another, even better approach IMO would be using the preprocessor
> that runs
> in the make process anyway. The CFLAGS/CPPFLAGS options " -save-temps
> -dD "
> (set in the environment before configure) force gcc to leave behind
> the
> preprocessed C-files (*.i and *.ii files) which contain all the
> assembled
> #includes and all the right conditional code according to the
> (possibly
> tweaked) environment/configuration.
> 
> Also (like in M$ Visual Studio) the expanded macro's symbols are
> catalogued
> which can be very, very important when you have to track references
> to a
> particular symbol. On the other hand you lose macro references but
> you can
> "grep" for that; ctags chokes on some macros anyway (see man page).
> 
> The *.i* files contain #-directives which identify origin files and
> line
> numbers.
> The option -dD leaves #defines in the source, so you get aliasing
> definitions (which can then be followed by the user).
> 
> After make, KDevelop can feed the intermediate files to
> 
> > ctags --langmap=c:.i,c++:.ii \
>   --line-directives \
>   --excmd=number \
>   --recurse \
>   <other options> \
>   <prjdir>
> 
> and then optionally dispose of them (along with any *.s file also
> left
> behind with -save-temps).
> 
> ctags understands the #-directives and maps symbols correctly.
> Duplicate
> #include expansion is automatically eliminated.
> 
> NOTE: The --langmap option crashes ctags on my machine if used
> together
> with --line-directives so you'd probably have to use
> 
> > find <prjdir> -name "*.ii" -print | ctags ... --language-force=c++
> -L-
> > find <prjdir> -name "*.i" -print | ctags
> ... --append --language-force=c -L-
> 
> instead until this is resolved (I submitted a bug).
> 
> This approach uses much more resources (intermediate disk space and
> time)
> than the current approach. But it yields the best results IMO. The
> method
> could be optimized by eliminating equal parts from the *.ii files
> (split
> files on #-directives, save first occurrence according to orgin file
> name).
> 
> -- Mark
> 
> 
> -
> to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body:
> unsubscribe »your-email-address«

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«