Missing (build) dependencies as found through trace mode.

[Mihai Moldovan]

* On 30.06.2014 04:06 am, Eric Gallager wrote:
> The way I would handle each of those categories would be:
>
>  - "mandatory": simple enough, just use a `port:`-style depspec

Yes, mandatory will be fixed right away. I already hit a few of those and am
fixing them as go.


>  - "recommended": use a `bin:`-style depspec, so the system versions
> can still satisfy it.

I will also try to gradually add "recommended" dependencies to port files, but
with lower priority, as those are not fatal. Not with a bin-style depspec,
though, as my "recommended" category basically only consists of MacPorts-only
software (so far.)


> 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.
 

>  - "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?

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

In such cases, I'd rather have "automatic dependencies" whenever some port is
installed enabling features or not. This basically happens when not building in
trace mode. However, it makes building non-deterministic...


>  - "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.)


>  - "???": 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/

Hohum.

Concerning cctools, we might be interested in using as, ar, ranlib et. al.
provided by the system, not MacPorts, as we already defaulting to the system
compiler. As such, I'd also ignore cctools whenever they come up (unless they
are promoted to "mandatory", as is the case for gcc4*. I'll file a bug report
about those build failures "later today".


Thank you for your input!



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4265 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140630/aec04270/attachment.p7s>