Missing (build) dependencies as found through trace mode.

[Eric Gallager]

On 6/29/14, Mihai Moldovan <ionic at ionic.de> wrote:
> * On 30.06.2014 04:06 am, Eric Gallager wrote:
>> Note that the autogen port does not fit in with
>> the rest of the autotools suite, despite its name
>
> gnutls has been searching for ${prefix}/bin/autogen. Not sure what it meant
> to find, exactly. I assumed the "autogen" port, but this may be wrong.
> It doesn't seem to be any part of GNU autotools.
>

Oh yeah, gnutls is actually the autogen port; I believe we had a
ticket about that: https://trac.macports.org/ticket/42728

>
>>  - "optional": make a separate variant for them, depending on what the
>> configure script does with them once it finds them, and use a
>> `port:`-style depspec in the variant. In the apache2 example, only the
>> first one of lynx/links/elinks is actually used, so only a dependency
>> on lynx would be necessary.
>
> Also in this case, I tend to put MacPorts-only software in this category.
> A lot of those unmet dependencies seem to be stemming from configure trying find
> software to enable additional features. Then again, who would really enable a
> "gtkdoc" variant for gnutls? Wouldn't it be better to just turn this stuff
> off via a --disable- or --without- configure switch?

This isn't gtk-doc specifically, but I do have a more general `+docs`
variant in my local gnutls2 Portfile... it also adds a dependency on
`bin:xsltproc:libxslt` and on texinfo, and uses the configure switches
as well: https://github.com/cooljeanius/LocalPorts/blob/master/devel/gnutls2/Portfile#L182

>
> Even better, cmake's list: (optional) port:bzr port:dpkg port:root5
> port:mercurial port:qt4-mac port:openssh port:subversion
> file:include/cairo/cairo.h:cairo port:fontconfig port:freetype
> port:gdk-pixbuf2
> file:include/glib-2.0/glib-object.h:glib port:gtk2
> file:include/pango-1.0/pango/pango.h:pango port:gettext port:python26

where are you getting this from?

>
>>  - "very optional": make a separate variant for them, and use a
>> `bin:`-style depspec in the variant. Since the addition of
>> dependencies of this type do not technically change how the software
>> actually gets built (which is what variants are supposed to be used
>> for), be sure to add a note or something mentioning that the variant
>> only exists to placate trace mode's pedantry (and anyone's own
>> personal OCD). Although some people might object to such a variant
>> even with such a note, so you might want to be careful with these
>> ones.
>
> Almost every software has a rather long list of this dependency type.
> Maybe just ignoring that and letting trace mode bark is good enough here?
> As already pointed out by you, there's no functional difference when building the
> software, whether with or without those dependencies.
>
> Creating a variant for everything sounds like a maintaining nightmare
> (and it doesn't help us anyway.)

Just to clarify, I didn't mean one variant per dependency, but rather
one mega "trace mode compliance" variant that has all of them. I
sometimes stick these in a variant where I make other
maintainer-specific changes, such as forcing autoreconfing, or
enabling additional warnings, and stuff like that.

>
>>  - "???": The cctools-headers one reminds me, it would be nice to have
>> a `header:`-style depspec, to match the `bin:`-style and `lib:`-style
>> ones
>
> Yeah, but that's not trivial. See, for instance, gl.h, provided by mesa
> and...
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/
>

Wouldn't that second one actually be <OpenGL/gl.h> as opposed to the
<GL/gl.h> that mesa installs, due to how framework headers are
written?