second call: dns/libidn staging broken

[Lowell Gilbert]

"Matthew D. Fuller" <fullermd at over-yonder.net> writes:

> On Wed, May 28, 2014 at 10:57:22PM -0400 I heard the voice of
> Lowell Gilbert, and lo! it spake thus:
>> 
>> Assuming my previous paragraph isn't wildly wrong, the easy
>> workaround would be to install emacs. That's just a hack; the right
>> fix (I think) is to add a port option to let it depend on emacs, or
>> for the port to adjust the plist dynamically.
>
> That doesn't sound right.  I don't have emacs installed, and
>
> % ls `pkg info -l libidn | grep \.el`
> /usr/local/share/emacs/site-lisp/idna.el
> /usr/local/share/emacs/site-lisp/punycode.el
>
> So I'd keep looking for the reason.

If this is a pre-staging libidn install (possible: the version and
revision info haven't changed since before that) then it makes my
theory more likely.

Otherwise, it certainly means that requiring emacs isn't a proper fix,
but if I'd been thinking clearly I would've realized that didn't make
sense anyway, because there are so many variants of emacs. Which is
exactly why the libidn configure script is so complicated in its
attempts to find the install location for those elisp files.  Also, it
seems to build okay on the package cluster under poudriere, so the lack
of emacs clearly isn't a general problem for the port.

Nonetheless, the specific error messages indicate that those elisp files
weren't copied into the staging area. I'm pretty sure from my analysis
of the configure script that this would only happen if it couldn't find
an emacs-like program to interrogate for the elisp load path, or if it
did find one and got a different load path than the one in the plist.