Missing (build) dependencies as found through trace mode.

[Mihai Moldovan]

* On 30.06.2014 06:19 am, Eric Gallager wrote:
> On 6/29/14, Mihai Moldovan <ionic at ionic.de> wrote:
>> * On 30.06.2014 04:06 am, Eric Gallager wrote:
>>>  - "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

So it's just missing the (default) --disable or --without switches, OK.


>> Even better, cmake's list: (optional) [huge list]
> where are you getting this from?

Oh, you know, building stuff in trace mode, taking a look at all sandbox
violations in all phases, matching those to ports manually and keeping a list
around. :)

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

That doesn't sound like a good idea. Trace mode is supposed to be the default
once hashing has been implemented to counter slow downs and we know it has no
adverse effects. As Clemens mentioned, we want to depend on system-provided
software as long as it's possible (i.e., a build doesn't fail.) Such a "trace
mode compliance" variant may be interesting for testing whenever a port fails
building with system-provided software. Turning it on would then tell you,
whether the MacPorts-packaged software fixes the failure. Still, we don't really
want to expose that in order to keep things deterministic.

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

Probably. But let's just pretend it would be <GL/gl.h> for a minute. I'm just
saying that implementing header: isn't easy due to all the locations header
files are scattered throughout the system.



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/20140703/ce36334e/attachment.p7s>