On Apr 11, 2016, at 5:02 PM, David Strubbe <[email protected]> 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. The dependency engine doesn't handle variants - it handles ports. If you need to depend on something, it should be in a port. Perhaps the fftw-3 'fix' is to have a separate port that has the fortran bits? I'm not sure how fftw-3 is structured. A /long/ time ago we split up the subversion-bindings ports into individual ports because although building them is faster if you can just do subversion +perlbindings and have the configure args be different - there are too many problems where people would have to rebuild (which are avoided by having a separate port). > I would say, on the contrary: if it did handle variants, it would be > unnecessary to pass variants down, because we would know automatically what > variants were needed. 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?) > 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). -- Daniel J. Luke _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
