Re: variants

On Apr 11, 2016, at 5:19 PM, David Strubbe wrote: > Of course it's not a full solution, but this seems like a fairly simple > advance that will solve some problems. and cause other, different problems. [why was this port installed with this variant? why didn't I get a binary archive?] install

Re: variants

On Mon, Apr 11, 2016 at 5:19 PM, David Strubbe wrote: > Of course it's not a full solution, but this seems like a fairly simple > advance that will solve some problems. Last year had a GSoC project to add a SAT-solver based dependency engine; it has, among other things, variant support. I belie

Re: variants

On Mon, Apr 11, 2016 at 5:07 PM, Daniel J. Luke wrote: > On Apr 11, 2016, at 5:02 PM, David Strubbe 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 f

Re: variants

On Apr 11, 2016, at 5:02 PM, David Strubbe 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 requ

Re: variants

On Mon, Apr 11, 2016 at 4:42 PM, Daniel J. Luke wrote: > > The ideal port has no variants (or at least has only default variants) - > it builds with all reasonable options and people don't have to think about > it. > I agree, but the question is what to do when the port does have variants. Consid

Re: variants

On Apr 11, 2016, at 3:29 PM, David Strubbe wrote: > Well, that is not the current behavior if a variant is specified manually. yes, when you enter a different command, you do get different results. > Why do you think it would be inappropriate to do that for default variants? Variants are 'speci

Re: variants

Then maybe we could have an option to pass down default variants? On Mon, Apr 11, 2016 at 4:09 PM, Bradley Giesbrecht wrote: > On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke > wrote: > >> On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto >> wrote: >> > If there is a reason behind treating defaul

Re: variants

> On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke > wrote: > On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto > wrote: > > If there is a reason behind treating default_variants and manually set > > variants, > > I’d like to know. > > I'm not

Re: variants

Well, that is not the current behavior if a variant is specified manually. What happens is: port install A +var does port install B +var && port install A +var. Why do you think it would be inappropriate to do that for default variants? On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke wrote:

Re: variants

On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto wrote: > If there is a reason behind treating default_variants and manually set > variants, > I’d like to know. I'm not sure what the initial reasoning was, but I think the current behavior is correct. When a port is installed as a dependency of som

Re: dependency question

On Apr 11, 2016, at 10:49 AM, René J.V. Bertin wrote: > Is it acceptable to have a sort of cyclic dependency no. -- Daniel J. Luke ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports

dependency question

Hi, Is it acceptable to have a sort of cyclic dependency of the kind: port A: depends_run-append port:B port B: depends_build port:A or even port B: depends_run-append port:A I'm not really certain yet of the actual dependencies in my particular case so I may not actually need this kind of h