variants

David Strubbe dstrubbe at macports.org
Mon Apr 11 14:19:16 PDT 2016


On Mon, Apr 11, 2016 at 5:07 PM, Daniel J. Luke <dluke at geeklair.net> wrote:

> On Apr 11, 2016, at 5:02 PM, David Strubbe <dstrubbe at macports.org> wrote:
> > I agree, but the question is what to do when the port does have
> variants. Consider, for example, ports with Fortran compiler variants that
> enable optional Fortran support, such as fftw-3. The current typical
> situation is that a port requiring fftw-3 with Fortran will waste time
> installing the default fftw-3 without Fortran, then give an error that it
> should have been installed with Fortran. By contrast, if the default
> variant could be passed on, fftw-3 would be installed with the needed
> Fortran support in the first place.
>
> unless fftw-3 was already installed in which case it still needs to give
> an error that it should have been installed differently.
>

Sure, that is exactly what currently does happen, and I would not propose
making any change in that respect.


>
> That would depend on how it's implemented (and what do you do if the port
> is installed with a different set of variants already? What if it's
> installed with conflicting variants?)
>

The implementation I propose is: pass on default variants like for
user-selected variants, nothing more or less. Then of course you would get
errors in the case you mention, just as you do right now.


>
> > Since the dependency engine does not consider them, that is why it would
> be very helpful to pass them down as it would solve many of the issues
> about "dependency on a variant" that are always being complained about on
> this list (such as the scenario I describe above).
>
> ... but it wouldn't be a complete solution to the problem (and there are
> other possible solutions that /would/ be).
>

Of course it's not a full solution, but this seems like a fairly simple
advance that will solve some problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160411/cc6297be/attachment.html>


More information about the macports-dev mailing list