On Tue, 26 Aug 2003, Rob Faulds wrote:
> Also, one of the older test harnesses here relies on an old (old) cywin
> which requires that cygwin1.dll and cygwin.dll (of this specific old
> version) be resident in the System32 directory or the tool fails.
??? Both of them? And they actualy have to be in System32, i.e. it
doesn't work if you install them in the bin directory of the test
harness itself? Strange.
> So, as a rule, I tried to avoid the cygwin .exe's and run MKS or other
> standalone w32 versions of .exes to lessen the pain.
Ah, so when you say "native w32", what you actually mean is "cygwin-free
w32" --- well, that's rather tricky. It may be possible to build cscope
with other Win32 toolchains than Cygwin, but I never really tried that.
This is a rather Unix-bound program, so some tricky aspects remain.
There's a patch in the Patch tracker at sourceforge.net that claims to
enable building of cscope with MS Visual C++:
http://sf.net/tracker/?func=detail&aid=713318&group_id=4664&atid=304664
Maybe that'll be of help to you.
> For the record, it was (in line mode)
> >>0pt_m.*IfInfo
-q mode behaves subtly different in some cases. Please check if you run
into the same problems using a query with a plain text string (no regex or
wildcards), too.
> > In case of doubt, please try to always use the cscope sources themselves
> > as a testbed for bug reports, so they can be reproduced by others.
>
> I only have the binaries -- outside of cygwin I don't have w32 .exe
> compilation set up.
The sources are available at SourceForge. See http://cscope.sf.net
You don't need a compilation setup to run cscope on a source tree.
Just cscope.exe and the sources.
[...]
> I went back to the non-working nt-emacs window and pasted the same commands
> int the shell and they continued to NOT work...who knows? I suspect that I
> may have had the (old) cygwin*.dll present in System32 when I started this
> nt-emacs window but I can't be sure.
That could in fact explain the -q mode failure. Cscope has to do some
prodding to convince the cygwin runtime that some files are to be written
in binary mode. Depending on cygwin.dll version and mount options, this
may well fail.
>
> I'm happy enough that I have inverted-mode back in any form. I'm going to
> try it under the (DJPCC) w32 cscope.exe, too, just for another
> datapoint...it didn't work (see below).
Please note that the DJGPP one is not a w32 version --- that's really a
DOS program, not a Windows application at all. It works quite well on
Windows platforms, but has some quirks. E.g. NT won't let DOS programs
access long file names, and W2K still has some serious bugs in its support
of this API. That's quite a shame, given that the same API works
perfectly in all 9x versions ever since the original edition of W95.
As to your examples, I've one observation to make: I usually advise
against using drive letters in paths presented to cscope, i.e. in
cscope.files. The problem with them is that they are, functionally,
absolute path names, but cscope can't recognize them as such because they
fail the "starts with a /" test. If you're using cygwin-built cscope, I
suggest you use the /cygdrive/u/dir/dir/file.ext convention instead.
> Now, I only have a wishlist item, that "-p <n>" would alter the output of
> line-mode, too, but that is subject for another time.
I suspect that may be a non-option --- line-mode is used by some
interfaces of cscope to editors, and they may well rely on the current
behaviour.
Which reminds me: have you tried xcscope.el in NT-emacs? Might be even
better than -p for your purposes.
--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.
|