[ITP] mlcscope-14.1.8
Dave & Diane
daveanddiane@kringlecottage.com
Fri Jul 28 02:58:00 GMT 2006
Hi Reini,
I've updated the packages at http://www.lowtechnet.com/cscope . Could
you take another look and let me know if anything else stands out or
needs fixing?
I have one issue that I'm not sure about.
I moved the notes.* files back in to the src dir, but I am not sure if
this is the best thing. Brian indicated that the notes files should go
in /usr/share/doc/mlcscope-14.1.8.
What I'm struggling with is that the src package is relative to usr/src
and the binary package is relative to /, so based on Brians comment I
put the notes files in /usr/share/doc/mlcscope-14.1.8 and hence in the
binary package. However I left the src/README in the src directory which
you pointed out references the notes files.
It makes sense that the src/README and the notes files should stay
together. If I leave them in the src package, I am going to have to
leave them in mlcscope-14.1.8/src or if they go in the binary package
they can go in usr/share/doc/mlcscope-14.1.8.
I don't think we want to do anything wierd like put files in the src
package that are "../share/doc/mlcscope-14.1.8" do we?
Since the src/README and src/notes* are all relevant to someone
compiling the code, I think the right solution is to leave the files in
/usr/src/mlcscope-14.1.8/src . Do you agree?
On a similar vain, the html files are in the binary package in
usr/share/doc/mlcscope-14.1.8 but you made a comment about these needing
to be in the src pkg. I run in to the same problem that the src package
is relative to /usr/src not / so I can't package /usr/share/doc...
without resorting to "../". Brian said the html files should go in
/usr/share/doc/... Since the html files are non-developer related, I
think it makes sense to leave them in the binary package. Please advise.
I appreciate your time looking at this.
Cheers
Dave
Reini Urban wrote:
> 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.
>
>
--
Diane & Dave
http://www.velvetstarbears.com/ http://www.kringlecottage.com/
Fortune: The difference between America and England is that the
English think 100 miles is a long distance and the Americans
think 100 years is a long time.
More information about the Cygwin-apps
mailing list