cygport: check setup.hint?

[Ken Brown]

On 7/20/2012 3:27 PM, Yaakov (Cygwin/X) wrote:
> On 2012-07-20 11:19, Ken Brown wrote:
>> On 7/20/2012 8:35 AM, Yaakov (Cygwin/X) wrote:
>>> The first version is now in cygport git master.  See the Packaging
>>> section of the manual for the variables you need to set in order for
>>> this to work, and be sure to remove your .hint files from $C.
>>
>> Wow, that was fast.  Thanks!
>
> I was already working on the setup.hint generation earlier this week; I
> just had to add in the dependency generation, the framework for which
> was there already in __list_deps (although I added to it).  That being
> said, it came together even faster than I had anticipated.
>
>> I tested it on cygport itself, emacs, and texlive.  I only found two
>> small glitches:
>>
>> 1. The setup.hint generated for emacs (but not emacs-X11) erroneously
>> listed perl and python in the "requires".  I'm attaching my .cygport
>> file and the associated patches in case you want to try to replicate
>> this.
>
> /usr/bin/grep-changelog is a perl script, and there are python modules

Ah, I missed that.  In the past it wasn't picked up by __list_deps.

> in /usr/share/emacs/$PV/etc used by python.el.  I'd say in this case
> that the perl dep is correct, but python is optional and could probably
> be ignored.
>
> I'm just not sure how to handle that.  AFAICS REQUIRES shouldn't
> override autogeneration; there are plenty of cases where it will be
> correct but incomplete and we just need to add.  Of course, you could
> just continue using a pkg_name.hint for just that subpackage, but that
> defeats the purpose.  I'm open to ideas here.

How about something like [PKG_]REQUIRE_EXCLUDES for packages that we 
don't want to require?

>> 2. If a package is listed in REQUIRES but then cygport also finds it as
>> a dependency, it gets listed twice in the generated setup.hint file.
>
> True; that's why the requires: are shown for autogenerated setup.hints,
> so you can detect and fix problems.  I'd say just don't do that.  The
> good news is that since we don't retest each tarball for its contents
> during the missing/conflicting files check anymore, rerunning 'package'
> isn't as expensive as it was previously.

Fair enough.

Ken