This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] mlcscope-14.1.8


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]