[Lxr-dev] [ lxr-Bugs-3490464 ] No identifiers Visible or selected
Brought to you by:
ajlittoz
From: SourceForge.net <no...@so...> - 2012-02-23 08:16:49
|
Bugs item #3490464, was opened at 2012-02-21 18:18 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3490464&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: genxref Group: current cvs >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Yannick Roberts (yor1001) Assigned to: Andre-Littoz (ajlittoz) Summary: No identifiers Visible or selected Initial Comment: LXR version 0.10.2 Database Mysql OS Ubuntu 10.04 Server Edition Plain Files I have spent hours trying to figure out why identifiers were not hyperlinked in the web interface, or the identifier search wasn't returning any results... The reason was ctags, or gnu ctags for that matter, which options seems to be different from exuberant's ctag. A patch to ensure exuberant ctag is used would save many alot of trouble. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-02-23 00:16 Message: Hi Yannick, Thanks for the output sample. The most interesting line is "Checking ctags version ... OK" with no version number! It comes from the "Exuberant ctags" detection line: test fails as expected and $1 is undefined. The bug is in "$version =~ /(\d+)/" line which does not take notice of previous test failure and extracts a version number (a version number is always present in a --version command; you could probe any other tool like gcc or ld and the test would succeed!). Then the real test "if ($1 < 5)" has a random results depending on the version value. I corrected genxref in CVS: immediately after the "Exuberant ctags" name test, the effective version is captured in "$version = $1;". The unchanged second line below ("$version =~ /\d+)/;") extracts the major version number from the previous test now unstead of the original string. To be sure, the level test is modified into "!defined($1) || $1 < 5" to guard against comparison between undef and 5 (I didn't check to see whether it succeeds or fails -- anyway it is better to be explicit). Sorry for the bug, I should have seen it from the start. If you know how to check things out of a CVS repository, get genxref from anonymous CVS. You can also download it through 'CVS Browse' from 'Code' drop-down menu. See lines 146-150. Otherwise you'll have to wait for 0.11 release (roughly in a one-month time frame after a full rereading of the user's manual). Regards and thanks once again for noticing this bug. ---------------------------------------------------------------------- Comment By: Yannick Roberts (yor1001) Date: 2012-02-22 14:56 Message: Found a reason... Line 137 in genxref seems to change $1 before it is checked $version =~ /(\d+)/; I moved line 137 to line 142 and it aborted just fine. ---------------------------------------------------------------------- Comment By: Yannick Roberts (yor1001) Date: 2012-02-22 14:40 Message: Here is the genxref output for gnu ctag Checking Perl version ... 5.10.1 OK 'ectagsbin' not equal to `which ctags` If this is a non-system copy, ignore this warning Checking ctags version ... OK Checking glimpse version ... 4.18.5 Checking glimpseindex version ... 4.18.5 Parameter 'swishbin' not defined - trying to find swish-e 'swishbin' temporarily adjusted to /usr/bin/swish-e Manually update lxr.conf for permanent setting Checking swishe version ... 2.4.7 Here is exuberants ctags Checking Perl version ... 5.10.1 OK Checking ctags version ... 5.8 OK Checking glimpse version ... 4.18.5 Checking glimpseindex version ... 4.18.5 Parameter 'swishbin' not defined - trying to find swish-e 'swishbin' temporarily adjusted to /usr/bin/swish-e Manually update lxr.conf for permanent setting Checking swishe version ... 2.4.7 I really am clueless at perl but it seems printing "$1" on line 138 of genxref before the $1<5 checks outputs 23, which is the emacs version. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-02-22 13:08 Message: Hi Yannick, I don't understand how you had no error indication. I checked LXR history: since release 0.10 there is a strong test in genxref to check Exuberant Ctags presence. The test is even buggy since it causes immediate termination instead of proceeding with other tests. With the output you sent, genxref should have die'ed on ctags check. Can run command: genxref --url=//url_for_your_tree --checkonly both for plain ctags and exuberant ctags and send output. You can force a particular ctags instance with proper setting of lxr.conf parameter 'ectagsbin'. Regards, ajl ---------------------------------------------------------------------- Comment By: Yannick Roberts (yor1001) Date: 2012-02-22 12:41 Message: Here is gnu ctags version output $ ctags --version ctags (GNU Emacs 23.1) Copyright (C) 2009 Free Software Foundation, Inc. This program is distributed under the terms in ETAGS.README and Exuberant Ctags version output Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert Compiled: Mar 6 2010, 15:35:10 Addresses: <dhi...@us...>, http://ctags.sourceforge.net Optional compiled features: +wildcards, +regex Apparently egemengozoglu does mention to install Exuberant ctags. (go figures I haven't seen this tutorial). Great Program btw. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-02-22 03:16 Message: I'll modify the preliminary tests in genxref. Could you send the output of command ctags -v or ctags --version on your system? This will help design an adequate test. Anyway, I'm a bit surprised that Ubuntu installs plain GNU ctags. This has not been mentioned by egemengozoglu on his site dedicated to Ubuntu installation (see http://egemengozoglu.com/blog/2011/07/lxr-installation-on-ubuntu-10-10/) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3490464&group_id=27350 |