Mail Archives: cygwin-apps/2001/12/08/15:03:55
Charles Wilson <cwilson AT ece DOT gatech DOT edu> writes:
> > hint="$(echo | cat $i/setup.hint - | grep -Ev '^(prev)|(curr|@) ' | sed -e 's/^\(\(category\)\|\(ldesc\)\|\(requires\)\|\(sdesc\)\|\(test\)\). */\1: /' | grep -v '^$')"
>
>
> Ummm...they are not broken. You just dislike some stylistic choices...
Well, setup.exe barfs on the. Quoting from inilex.l:
"sdesc:" return SDESC;
"ldesc:" return LDESC;
"category:" return CATEGORY;
"requires:" return REQUIRES;
So, after reading this and the setup.hint spec on cygwin.com, I
implemented hinting, in gen-ini.sh and it *broke* setup.exe. So, I
considered it a bug, and wanted you to know about it. But if you
don't care, fine.
> Also, blindly removing the prev/curr/test markers is not a good thing
> either.
For me, it's *a lot* better than a barfing setup.exe.
> Sometimes (when upset's automatic version parser fails)
Who is `upset'? I haven't seen my version parser fail, but in general
one should not provide the same information from two sources. Which
do you trust when they do not match? Why not just have a sane
archive, or fix setup.ini by hand if you don't like it?
If a version parser fails, the offending package (filename) should be
fixed, imo.
> the hints may just be old.
Yes, I guess that they're old. If old things don't get fixed, the get
bitrot.
> In my case, I will update a given setup.hint to follow that new
> *recommendation* (not requirement) the next time I update the package
> controlled by it, and not until then.
Indeed, parts of the cygwin archive are a bit of a mess, but it's too
bad if it's by principle, and not for want of time.
> If it ain't broken (and it ain't) then don't fix it.
Well, sorry to bother you then. I can keep kludging around this small
thing too.
Jan.
--
Jan Nieuwenhuizen <janneke AT gnu DOT org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
- Raw text -