* On 30.06.2014 06:19 am, Eric Gallager wrote: > On 6/29/14, Mihai Moldovan <io...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev