variants

[Daniel J. Luke]

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.

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