From: <no...@so...> - 2002-04-29 14:13:48
|
Bugs item #547316, was opened at 2002-04-23 01:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=547316&group_id=4664 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Matthews (mikematt) Assigned to: Hans-Bernhard Broeker (broeker) Summary: Irratic behavior with cscope 15.3 Win2K Initial Comment: Installed latest version of Cygwin onto a Windows 2000 SP 2 system, using the DOS text files option. Built cscope from 15.3 source files in Cygwin Bash shell (cygwin1.dll version 1003.10.0.0 and cygncurses6.dll), using the following commands: ./configure make make install I then copied the cscope.exe file to a Windows 2000 SP 2 system (with the cygwin1.dll version 1003.10.0.0 and cygncurses6.dll on the system and their location added to the Windows PATH variable). I created a file named "cscope_files" that has a list of relative paths (from the root of the drive I am running cscope from) to all of the .c, .cpp, and .h files that are part of the build. There are 1722 files in the build in various directories. I then entered the following command in the MS-DOS shell window: T:\clark>cscope -bqu -f t:\clark\cscope.out -i t:\clark\cscope_files and I got the following: cscope: cannot open file t:\clark\cscope.out I then tried the following command (used forward slashes instead of backslashes): T:\clark>cscope -bqu -f cscope.out -f cscope_files and I got the following cscope: no source files found I then tried the following command (used forward slashes instead of backslashes): T:\clark>cscope -bqu -f t:/clark/cscope.out -i t:/clark/cscope_files and I got the following: cscope: cannot create inverted index; ignoring -q option cscope: removed files t:/clark/ncscope.out.in and t:/clark/ncscope.out.po Question: why is cscope doing more when I give it file paths with forward slashes when the Windows shell use backslashes? I then tried invoking cscope and pass it the locatations of the cscope.out and cscope_files files: T:\clark>cscope -f cscope.out -i cscope_files Cscope the displayed the text screen and says "Building symbol database". After it is finished building the database, it displays "Press the RETURN key to continue:" I pressed the "Enter" key and the cursor appears in the middle of the line "Find this global definition:". It looks like the initial cursor position in down one more line than it should be. I then enter the name of a data type in the "Find this C symbol:" and I get the following output: Cscope version 15.3 Press the ? key for help C symbol: uint8_t File Function Line 0 \draco_01 \mech\src\cbio\cbio_acumen.cpp <global> 36 uint8_t page_mode_write_ok = 0;1 \draco_01 \mech\src\cbio\cbio_acumen.cpp <gl obal> 38 uint8_t page_mode_write_ok = 1;2 \draco_01\mech\src\c bio\cbio_acumen.cpp <global> 41 uint8_t page_m ode_read_ok = 0;3 \draco_01 \mech\src\cbio\cbio_acumen.cpp <global> 43 uint8_t page_mode_read_ok = 1;4 \draco_01\mech\src\cbio\cbio_acumen.cpp <global> 324 uint8_t *result)5 \draco_01\mech\src\c bio\cbio_acumen.cpp <global> 432 uint8_t *srcPt r)6 \draco_01 \mech\src\cbio\cbio_acumen.cpp <global> 573 uint8_t *destPtr)7 \draco_01 \mech\src\cbio\cbio_acumen.cpp <global> 711 uint8_t *srcPtr)8 \draco_01\mech\src\cbio\cbio_acumen.cpp <global> 842 uint8_t9 \draco_01\mech\src\cbio\cbio_acu men.cpp <global> 846 static uint8_t acumenByte; a \draco_01 \mech\src\cbio\cbio_adc.cpp <global> 102 uint8_t controller_channel;b \draco_01 \mech\src\cbio\cbio_adc.cpp <global > 103 uint8_t adc_mux;c \draco_01\mech\src\cbio\cbio_adc.cpp <global> 668 uint8_t mux[CBIO_MAX_CONTROLLER_C HANNELS];d \draco_01 \mech\src\cbio\cbio_adc.cpp <global> 899 uint8_t offsetDacValue [ENDEV_NUM_CHANNELS] = {e \draco_01 \mech\src\cbio\cbio_adc.cp p <global> 971 STATIC uint8_t iDefaultEndevA DCMuxCh = cbioChannelMapTable [CBIO_CHAN_ENDEV_DEFAULT].mux[0];f \draco_01 \mech\src\cbio\cbio_adc.cpp <global> 988 uint8_t iMux,g \draco_01\mech\ src\cbio\cbio_adc.cpp <global> 1000 STATIC vo id SetSynergyADCMux( cbioController_t, uint8_t, boolean_t );h \draco_01\mech\src\cbio\cbio_gbl.h <global> 212 uint8_t bDisplayToConsole = 0;i \draco_01 \mech\src\cbio\cbio_gbl.h <global> 213 uint8_t bDisplayToUDW = 1;j \draco_01 \mech\src\cbio\cbio_gbl.h <global> 214 uint8_t bUDWThread = 0;k \draco_01\mech\src\cbio\cbio_gbl.h <global> 215 uint8_t bOutputToFile = 0;l \ draco_01 \mech\src\cbio\cbio_gbl.h <global> 220 extern uint8_t bDisplayToConsole;m \draco_01 \mech\src\cbio\cbio_gbl.h <glo bal> 221 extern uint8_t bDisplayToUDW;n \draco_01\mech\src\cbio \cbio_gbl.h <global> 222 extern uint8_t bU DWThread;o \draco_01 \mech\src\cbio\cbio_gbl.h <global> 223 extern uint8_t bOutputToFile;p \draco_01\mech\src\cbio\cbio_gpio.cpp Find<global>symbol: 189 uint8_t reg[CBIO_NUM_CONT_TYPES];q \draco_01\m Find this global def Find functions called by this function: Find functions calling this function: Find this text string: Change this text string: Find this egrep pattern: Find this file: Find files #including this file: If I press a number key, then a file is loaded into less.exe (I have the VIEWER variable set to less.exe) just fine. I press "Q" to quit less, and then the Tab key to put the cursor at the end of the line "Find this C symbol:", which the cursor is now in the correct position. This does not always happen, though. SOmetimes the cursor is lined with the search option lines and sometimes it is not. If I enter the name of a file that is #included, such as "intLib.h", in the "Find files #including this file:" line, then I get the following display: Files #including this file: intLib.h File Line 0 \draco_01 \mech\src\dropdet\icd_dropDetect.cpp 31 #include <intLib.h> 1 \draco_01 \mech\src\pen\pencntrl.cpp 45 #include <intLib.h> 2 \draco_01 \old\i2cdriver\I2CDriver.cpp 93 #include "intLib.h" 3 \draco_01 \old\mech\carmotor.cpp 28 #include "intLib.h" 4 \draco_01 \old\mech\dcmotortimer.cpp 32 #include "intLib.h" 5 \draco_01 \old\mech\heater.cpp 24 #include "intLib.h" 6 \draco_01 \old\mech\print.cpp 31 #include <intLib.h> 7 \draco_02 \rt\src\driver\util\rtHAL.cpp 21 #include "intLib.h" 8 \draco_03 \error_mgr\error_mgr_shim.cpp 25 #include <intLib.h> 9 \draco_03 \event_mgr\eventcomponent.cpp 43 #include "intLib.h" a \draco_03 \old\system\Perf.cpp 23 #include "intLib.h" b \draco_03 \old\system\PerfRAM.cpp 23 #include "intLib.h" c \draco_03 \old\system\SysUtil.c 32 #include <intLib.h> d \draco_03 \old\system\Watchdog.c 87 #include "intLib.h" e \draco_03 \old\system\os_mw.c 69 #include "intLib.h" f \draco_03 \old\ui\stateControl\UserIface.cpp 105 #include <intLib.h> g \draco_03 \sysmgr\initprimo.cpp 33 #include <intLib.h> h \draco_03 \sysmgr\systest.cpp 23 #include "intLib.h" i \draco_interfaces\old\include\HAL_pub_types.h 107 #include <intLib.h> j \draco_interfaces\old\include\ImpalaRegisters_pub_api.h 41 #include <intLib.h> k \draco_interfaces\old\include\OSPub.h 28 #include "intLib.h" l \draco_interfaces\old\include\OS_pub_api.h 22 #include <intLib.h> m \draco_interfaces\old\include\readreg.h 27 #include "intLib.h" n \fary\bravo\config.coldfire\RedOSImpl.h 33 #include <intLib.h> o \vpr_libraries\RedOS\src\Polaris\redosheader.h 33 #include <intLib.h> p \vpr_libraries\RedOS\src\Polaris\redospriv.h 122 #include <intLib.h> q \vwcf_t2 \target\config\polarisImpala\intlib.h 21 #include "/vwcf_t2/target/h/intLib.h" Find this C symbol: Find this global definition: Find functions called by this function: Find functions calling this function: Find this text string: Change this text string: Find this egrep pattern: Find this file: Find files #including this file: I have tried using the -p option to limit the number of path elements displayed by cscope. As you can see in the above examples, cscope 15.3 prints the entire path that was extracted from the cscope_files file. It would easier on the user to just see the file name and its parent directory, which should work with the "-p 2" option. When I entered the following command: T:\clark>cscope -p 2 -f cscope.out -i cscope_files and I then searched for files that #include "intLib.h", all of the file paths listed in the "File" column are displayed as the entire file path, not just the last two path components (file name and parent directory). I do not have these problems on version 12.9 of cscope on my HP-UX 10.20 workstation (I don't know how relevant this is as I do not know where this cscope sources came from). Did I not build the cscope 15.3 files correctly with Cygwin or is this just the general behavior of cscope on a Windows 2000 system? To summarize my questions: 1) Why does cscope in a Windows command shell prefer forward slashes instead of backslashes? 2) When I pass entire file paths for cscope.out and cscope_files to cscope, it says it cannot open the cscope.out file. But when I invoke cscope and just pass it the filenames "cscope.out" and "cscope_files" without the paths, it then runs and builds a database. 3) How comew sometimes the list of files that a search term is found is all messed up on the screen and othertimes the list is not messed up? 4) The -p option seems to have no effect on the list of files a search term is in. 5) Is there some special configuration I should be building the cscope 15.3 source file with Cygwin or for use on a Windows 2000 system? Attached is the cscope.exe binary built with Cygwin on a Windows 2000 system. Requires the Cygwin cygwin1.dll and cygncurses6.dll files. Thanks. -Michael ---------------------------------------------------------------------- >Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-04-29 16:13 Message: Logged In: YES user_id=27517 The breakage in your CVS compilation didn't come from a syntax error in Makefile.am, but from inconsistent states of the autoconf/automake generated files. This happens because CVS jumbles up all timestamps on checkout --- 'make' tries to be clever about it, but doesn't quite manage to get it right, esp. not for Cygwin, with its two different version of autoconf and automake each, and the automagic machinery that decides which of those to use. You should call autoreconf --gnu before running configure. ---------------------------------------------------------------------- Comment By: Michael Matthews (mikematt) Date: 2002-04-24 20:45 Message: Logged In: YES user_id=467900 Hello, I used WinCVS to get the latest cscope files from SourceForge. I copied the cscope files to another location and made them all write-able, since CVS makes them read- only until they are checked out. I then opened a Cygwin BASH shell, changed directories to the cscope files and then entered the following command: ./configure After that, I entered "make" and came across some make errors. See the attached text file for more details (the formatting will get screwed up if I paste the text in the submittal web page). I don't have time to debug the Makefiles, so I will just look for something else. Thanks for your help. -Michael ---------------------------------------------------------------------- Comment By: Hans-Bernhard Broeker (broeker) Date: 2002-04-24 04:28 Message: Logged In: YES user_id=27517 First of all, please try to if the CVS version helps you with these problems. Several changes for the benefit of Cygwin have been made since the 15.3 release, some of which may be causing the problems you see. The error on this one: > T:\clark>cscope -bqu -f cscope.out -f cscope_files is obvious: you mistyped the -i option. > 1) Why does cscope in a Windows command shell prefer > forward slashes instead of backslashes? It's not just the shell --- it's cscope itself, and that's because it's a Unix-borne program which isn't 100% fully ported to accept Windows-ish path names. /cygdrive/e/blah/file.c style names should always work, though. It's a question of toolchain coherence --- the whole Cygwin is Unix as Unix can, given the fact the real OS it's running on is MS Win32. There are some deep conceptual problems lurking around here. E.g. on Unix, there are only two types of pathnames: relative and absolute, the latter of which are distinguished by starting with a /. On DOS/Windows, there are two more types, distinguished by an additional drive letter in front of the name. I.e. all of these four are different classes of path names: d:\directory\file.ext d:directory\file.ext \directory\file.ext directory\file.ext The value of both the current drive and the whole collection of individual "current directories" for all(!) drives influences the meanings of the latter three of these classes, whereas in Unix only a single current working directory would. This mightily confuses all Unix-ish programs using lists of pathnames and trying to treat relative and absolute pathnames differently. > 2) When I pass entire file paths for cscope.out and > cscope_files to cscope, it says it cannot open the > cscope.out file. No. That it only did when you used backward slashes. > 3) How comew sometimes the list of files that a > search term is found is all messed up on the screen > and othertimes the list is not messed up? Hard to tell off-hand. Could be a remaining DOS<->Unix textfile issue. Again: please check CVS before we delve deeper into this. It could also be a fundamental bug in Cygwin's ncurses or terminal emulation --- which really is not exactly the most stable beast this side of the sun. > 4) The -p option seems to have no effect on the list > of files a search term is in. Another / vs. \ issue, I guess. cscope won't cut away path components separated by \, because a \ isn't a directory separator in its book. You really will be better of using /cygdrive style pathnames with forward slashes, also in your cscope_files listing. ---------------------------------------------------------------------- Comment By: Michael Matthews (mikematt) Date: 2002-04-23 01:36 Message: Logged In: YES user_id=467900 Since the cscope.exe binary for Windows 2000 is apparently too big to submit (it is 323 KB in size), I have attached a text file of my main text above, since the cscope display output will be better formatted in the text file instead of in the bug report web page. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104664&aid=547316&group_id=4664 |