Dave & Diane schrieb:
Hi Reini,
Thanks for your time to look at this so extensively. See my notes below.
Reini Urban wrote:
No GTG.
1.
$ usr/sbin/mlcscope.exe
cscope: no source files found
Usage: cscope [-abcCdeklLoqrRtTuUV] [-f file] [-F file] [-i file] [-I
dir]
[-m lang] [-p number] [-P path] [-s dir] [-x ext]
[-[0-8] pattern]
-a Ask for subset of files to search in "Find this egrep
pattern:"
-b Build the database only.
-c Use only ASCII characters in the database file, that is,
do not compress the data.
-C Ignore letter case when searching.
-d Do not update the database.
-e Suppress the <Ctrl>-E command prompt between files.
-f "file" Use "file" as the database file name instead of
the default (cscope.out).
-F "file" Read symbol reference lines from file, just
like the "<" command.
-i "file" Read any -I, -p, -q, and -T options and the
list of source files from "file" instead of the
default (cscope.files).
-I "dir" Look in "dir" for #include files.
-k Kernel Mode - don't use /usr/include for #include files.
-l Line-oriented interface.
-L Do a single search with line-oriented output.
-m "lang" Use lang for multi-lingual cscope.
-num "pattern" Go to input field num (counting from 0) and find pattern.
-p n Display the last n file path components.
-P "path" Prepend path to relative file names in pre-build
databases.
-q Build an inverted index for quick symbol seaching.
-r Display as many lines as possible (return required).
-R Recurse directories for files.
-s "dir" Look in "dir" for additional source files.
-T Use only the first eight characters to match against
symbols.
-u Unconditionally build the database.
-U Check file time stamps.
-V Print the version number.
-x "ext" Use extended menu with option "ext".
$ /usr/src/mlcscope/usr/sbin/mlcscope.exe `find -name \*.c`
cscope: converting to new symbol database file format
cscope: building symbol database
Can you patch the source everywhere to reflect the correct name
mlcscope and not cscope please.
I will discuss this with the maintainer of cscope/mlcscope at Lucent
because its not really a cygwin specific issue. I can create an
appropriate patch in the meantime.
Please. I might be tended to ITP cscope from sf.net,
so there should be no confusion.
I got no cscope (sf.net) build errors.
2.
$ tar tfj mlcscope-14.1.8-1.tar.bz2
usr/sbin/
usr/sbin/mlcscope.exe
usr/share/
usr/share/doc/
usr/share/doc/Cygwin/
usr/share/doc/Cygwin/mlcscope-14.1.8.README
usr/share/doc/mlcscope-14.1.8/
usr/share/doc/mlcscope-14.1.8/COPYING
usr/share/doc/mlcscope-14.1.8/cscalls.html
usr/share/doc/mlcscope-14.1.8/cscope.html
usr/share/doc/mlcscope-14.1.8/index.html
usr/share/doc/mlcscope-14.1.8/mlcscope.html
usr/share/doc/mlcscope-14.1.8/notes.cygwin
usr/share/doc/mlcscope-14.1.8/notes.dos
usr/share/doc/mlcscope-14.1.8/notes.w95
usr/share/doc/mlcscope-14.1.8/notes.win32
usr/share/doc/mlcscope-14.1.8/README
usr/share/man/
usr/share/man/man1/
usr/share/man/man1/cscalls.1.gz
usr/share/man/man1/cscope.1.gz
usr/share/man/man1/mlcscope.1.gz
Either cscalls and cscope binaries are missing, or the docs are wrong.
Since this was my first time adding a package to cygwin I was trying to
only make the binaries available that made sense in a cygwin environment
and not bite off too large a problem at once.
cscalls is used by dt which I don't think is currently available in
cygwin. I was undecided whether to remove the man pages or not since I
wasn't trying to package cscalls. If you think it is appropriate I can
remove the man pages etc. Also, I haven't tested cscalls functionality
so wanted to err on the cautious side by not saying it was available.
so please delete
usr/share/man/man1/cscalls.1.gz
usr/share/man/man1/cscope.1.gz
cscope and mlcscope are very different because cscope uses one parser
and mlcscope uses a different parser based on the language of the file.
I didn't pursue making the cscope executable available for two reasons.
First and foremost, there is already a version of cscope on sourceforge
(which you reference), and it is unrelated the Lucent version of cscope
and has different functionality. Different advantages and disadvantages.
If I introduce cscope and mlcscope, I risk creating confusion between
Lucent cscope and Sourceforge cscope. I was hoping to avoid doing that,
so I chose to only package mlcscope. The Lucent package however contains
both.
Secondly, I had trouble getting the lex parser to compile for cscope.
Given that I didn't want to create confusion in the community between
the two, I didn't spend much time trying to fix that and decided to just
package mlcscope.
I would welcome your direction on this. If you think it appropriate to
remove the man pages for cscope (and cscalls) or provide the tools with
the documentation clearly stating that its different than the
sourceforge version of cscope.
3. Why usr/sbin ?
We would rather prefer usr/bin
Brian in http://www.cygwin.com/ml/cygwin-apps/2006-06/msg00073.html also.
Ah - my bad. I fixed the missing usr/ in the path as Brian pointed out
but forgot to change it to bin. Will fix.
4. Missing docs in src pkg:
src/README refers to those missing files:
notes.dos
notes.cygwin
notes.w95
notes.win32
in the src package. Those are only in the binary package. The html
docs are also missing from the src pkg.
Will fix.
Better include only the original src pkg, the build script and the
patches. BTW: With cygport it will be only 3 lines plus the patch.
5. Missing cscalls
The src contains a cscalls.sh which should installed to usr/bin/cscalls
so no cscalls
Ref discussion above
6. Missing cscope
Is this enough?
Ref discussion above
no cscope binary and no man
cd usr/bin
ln -s mlcscope.exe cscope
I don't think so, because the upstream cygwin package contains
different binaries with different functionality.
I didn't look at the binary package since I know they were compiled
quite some time ago and there are newer versions of cygwin out since. I
forgot the msdos versions were in the binary package. Since the msdos
versions rely on pdcurses etc I don't think it would be appropriate to
include in a cygwin package. Do you agree?
http://www1.bell-labs.com/cgi-user/wwexptools/gensnapshot?cscope
$ tar tfz cscope.tar.gz
bin/cscope.exe
bin/mlcscope.exe
bin/cscalls
lib/msdos/cscop386.exe
lib/msdos/cscope.exe
lib/msdos/mlcscope.exe
lib/msdos/cscope95.zip
lib/toolnews/cscope
lib/toolhist/cscope
lib/cscope/
lib/cscope/COPYING
man/man1/cscope.1
man/man1/mlcscope.1
man/man1/cscalls.1
cscope.sn.net:
cd /usr/src/mlcscope/cscope-15.5-1/inst/usr/bin
$ ./cscopy -h
Usage: cscope [-bcCdehklLqRTuUvV] [-f file] [-F file] [-i file] [-I
dir] [-s dir]
[-p number] [-P path] [-[0-8] pattern] [source files]
7. orisrc download url
I found nowhere a location where to find more information of the
original src package and where to download it.
Either http://www1.bell-labs.com/project/wwexptools/cscope/ or
http://cscope.sourceforge.net/ should be mentioned somewhere.
The was mentioned in usr/share/doc/Cygwin/mlcscope-14.1.8.README :
Lucent cscope.
--------------
You can find the Lucent version of cscope in its raw form and for other
platforms at: http://www.bell-labs.com/project/wwexptools/packages.html
I can clarify to state source and binaries for all platforms.
8. The latest cscope release is 15.5 (http://cscope.sourceforge.net/)
Probably without java support.
But if you provide a cscope binary and/or man page you should explain
how to resolve the conflict if someone wants the newer cscope package.
cscope-15.5 contains also ocs, webcscope and xcscope, but no -m option.
I disagree with the term latest - the sourceforge version is unrelated
to the Lucent version. They are from different branches in the source
history of cscope and there are no efforts to cross port features as far
as I am aware. This history of this can be found on the bell-labs
website you mention above:
"CSCOPE has some older variants available publicly, which originated
within Lucent (or AT&T prior to the divestiture), when CSCOPE was
submitted to UNIX, when this was owned by AT&T. This early version was
sold of as part of UNIX System Labs, which was bought by Santa Cruz
Operation and subsequently released as Open Source. As such, version
11.4 was enhanced as Open Source and renamed as version 15. However,
Lucent CSCOPE progressed within AT&T and Lucent over the past 15 years,
as version 12 and 13 and has significantly more functionality through
its use over many years. MLCSCOPE was created to adapt CSCOPE to a
Multi-Lingual approach and providing JAVA support.
This history unfortunately means there are two separate source trees for
cscope. This was part of the thinking to only provide mlcscope.
What gets really confusing is the Lucent package identifies cscope and
mlcscope with different versions. cscope is version 13, mlcscope is
version 14.
Perhaps I should add a comment to
usr/share/doc/Cygwin/mlcscope-14.1.8.README explaining this more
yes, please quote the paragraph. people will be asking this.
If I do add cscope to cygwin, I need to figure out how to provide both
executables with different version number from the same source package.
Advice on this would be appreciated if we go that path.
Rather stay with mlcscope alone as this seems to be better.
BTW: I am also tempted to add php support to mlcscope.
perl will be a bit harder in flex. :)
9. setup.hint misses libncurses8
Will fix.
So for a mlcscope package for java support it would be enough to fix
those issues, including fixing name, the packaging, remove the cscope
man packages and fix the docs.
Thanks again! I appreciate your time, and hope to have these issues
fixed soon. I look forward to your thoughts.
--
Reini
