[ITP] mlcscope-14.1.8

[Reini Urban]

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