On Mon, Apr 11, 2016 at 5:07 PM, Daniel J. Luke <dl...@geeklair.net> wrote:
> On Apr 11, 2016, at 5:02 PM, David Strubbe <dstru...@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.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
