I am interested in becoming a maintainer for a new package mlcscope.
I have attached the setup.hint
The original distribution of mlcscope can be found at
http://www.bell-labs.com/project/wwexptools/packages.html as part of the
I have placed a source and binary set of archives for the cygwin package
I have not created a cygwin package before, so if I screwup in this
process, I apologise in advance.
Before sending email to cygwin-announce I have a few questions about the
1) The original vendor package does not come with a configure command.
Should I include a basic configure command that always returns success
or should I simply not include a configure command?
2) Since there is no real configure command, can I expect a lot of
problems due to differences in people configurations?
3) I think I have followed the instructions on
http://cygwin.com/setup.html accurately. Can someone look these packages
over prior to me officially submitting to cygwin-announce and provide
Diane & Dave
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.
sdesc: "Lucent version of cscope for multiple languages (mlcscope)"
ldesc: "Venerable C Source Browser developed by Lucent Technologies."
requires: flex ncurses
Dave & Diane wrote:
> I have placed a source and binary set of archives for the cygwin package
> at http://www.lowtechnet.com/cscope
> I have not created a cygwin package before, so if I screwup in this
> process, I apologise in advance.
> Before sending email to cygwin-announce I have a few questions about the
> package contents.
Whoa there, you only send mail to cygwin-announce after the package has
been uploaded, and before it can be uploaded it needs a GTG review and
at least 5 votes (existance as a stable package in a well-known linux
distro can be used in lieu of votes.)
> 1) The original vendor package does not come with a configure command.
> Should I include a basic configure command that always returns success
> or should I simply not include a configure command?
The lack of configure script is not a problem per se, as long as you
document all the steps necessary to turn the source package into the
binary package in the Cygwin-specific README file.
> 2) Since there is no real configure command, can I expect a lot of
> problems due to differences in people configurations?
That would depend on how the code is written. Given that Cygwin implies
x86 and Microsoft Windows, then if the program compiles and runs fine on
your Cygwin installation there's a pretty good chance it will function
identially on any Cygwin installation. But that's not to say there
might not be problems with e.g. DOS line endings or paths with spaces in
them, but those aren't the kind of things that a configure check would
> 3) I think I have followed the instructions on
> http://cygwin.com/setup.html accurately. Can someone look these packages
> over prior to me officially submitting to cygwin-announce and provide
There are a number of problems with your binary package.
It includes only a single file, /sbin/mlscope.exe. This should almost
certainly be in /usr/bin and not /sbin.
The source package contains man pages, HTML documentation, even your
README in the CYGWIN-PATCHES dir. All of these need to be in the binary
package, otherwise no user will ever see them. The binary package
contains all the files you want actually installed on the user's
The Cygwin specific README (i.e. CYGWIN-PATCHES/README) should be in the
binary package as usr/share/doc/Cygwin/mlcscope-13.8.8-1.README.
The HTML and upstream README, COPYING, notes.* (etc.) should all go into
The man pages should be gzipped and placed into /usr/share/man/man1/.
Your setup.hint contains a dependancy on flex, but this appears to be a
compile-time dependancy as libfl only exists as a static library. If
this is the case you need to list flex in the (currently missing) "build
packages required" section in your Cygwin-specific README, but not in
setup.hint. The "requires" line in setup.hint is only for runtime
Finally, a note about your source patches: All of the things that you
patch (renaming getline() and not using d_ino) are non-issues in current
Cygwin snapshots and the upcoming 1.5.20. In the next release of Cygwin
getline will not be defined unless you define _GNU_SOURCE, and d_ino
will be usable and functional -- if you wait for 1.5.20 this should not
require any patches.
Dave & Diane wrote:
> How long do old versions get supported?? If I wait, I wouldn't want
> someone to download the new package but still be running on the old
> cygwin even though we have moved up to the latest version. For
> example, I see 1.5.18 is still available in setup.
For the getline issue, it won't matter at all, since the whole point is
to not use the getline() in the Cygwin DLL. 1.5.20 just makes this
easier by not defining getline() by default.
For the d_ino issue, it may be a bit less clear. If I'm remembering
correctly, d_ino was supported for quite some time, was
deprecated/removed in .18 or .19 (but still supported in a backwards
compatible way for binaries linked against an older version of the DLL)
and then was reintroduced again in .20 with new fixes. So, it may be
that regardless of what you do you'll be fine here. I'm not sure.
In any case for a new package I wouldn't worry about it that much. If
you want to wait until .20 and release it without a patch, and mention
in your release announcement that .20 should be used that would be
fine. Or since you already have the patch you can go ahead and release
it now without d_ino checking and it should work for any version.
> I guess I could
> leave the source package unpatched, and create a configure command
> that checks the cygwin version, applying the patch appropriately.
I think that would be a lot more confusing than it's worth, especially
since there's no configure script right now at all. Supporting
source-builds of older versions of the DLL is certainly outside of the
normal range of things you have to worry about. You can just document
in the Cygwin-specific README in the "build time requirements" that the
user needs version X (where X is whatever is the current DLL version at
the time the package was created.)
|Free forum by Nabble||Edit this page|