This is the mail archive of the
mailing list for the Cygwin project.
Re: setup.hint documentation issues
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 17 Feb 2016 14:31:02 +0000
- Subject: Re: setup.hint documentation issues
- Authentication-results: sourceware.org; auth=none
- References: <56B9E71A dot 7010002 at dronecode dot org dot uk> <877fid3cle dot fsf at Rainer dot invalid>
On 09/02/2016 19:31, Achim Gratz wrote:
Jon Turney writes:
I'd suggest that double-quoting of those keys is made mandatory, and
embedded double-quotes are forbidden, as this permits simpler
processing of this text, lexing character by character.
OK, although we might need some sort of escaping in the long run.
Yes, I have no problem with later adding escaping e.g. using '\', if
needed, since that can written with a character by character lexer.
But writing a replacement setup.hint parser, while maintaining
bug-for-bug compatibility with the existing behaviour, requires a
line-by-line processing with various transformations...
upset knows enough to omit packages which have no install tarfiles
(i.e. are source-only) from from setup.ini, irrespective of 'skip'.
However, the presence of 'skip' also causes the package to be omitted
from the HTML package list.
I could be wrong, but it seems it may have been intended to deal with
packages that became obsolete, but the previous version was still kept.
Any package marked 'skip' is completely omitted from setup.ini, so setup
won't do anything with it, so I don't think that can be the use for it.
I think cygport's behaviour has changed over time, but currently will
mark source-packages as 'skip', however there are several packages
that are source-only (e.g. attica), that are missing 'skip'.
So the proposal is to remove skip or make it mandatory for source-only
I'm not sure. I think I tend towards removing it, since it doesn't add
But currently cygport generates a setup.hint for source-only package
which only contains 'skip'. I'm not sure that's the best idea, as
having no sdesc, etc. means we can't describe the source package.