Ryan Schmidt writes: > On Oct 1, 2014, at 12:23 AM, Sean Farley wrote: > >> Ryan Schmidt writes: >> >>> On Sep 30, 2014, at 11:25 PM, Sean Farley wrote: >>>> >>>> Ryan Schmidt writes: >>>> >>>>> On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: >>>>>> >>>>>> Variants create a new node in the dependency DAG. Subports create a new >>>>>> node in the dependency DAG. There is no topological difference. The only >>>>>> difference is in how they were implemented. >>>>> >>>>> As far as I understand, variants are not involved in the dependency DAG >>>>> in MacPorts at this time. Only ports/subports are. >>>> >>>> Variants *in MacPorts* are not involved in the DAG *due to >>>> implementation*. They do indeed change the graph. >>> >>> I guess I'm not familiar with what graph you're talking about. I'm only >>> concerned with how dependencies work in MacPorts, not some other real or >>> hypothetical package manager. >> >> I'm not talking about a package manager, just the dependency graph. What >> I'm trying to point out is that variants change the graph. For example, >> look at the wonky code of the dependents of cairo, checking for >> cairo+quartz vs. cairo+x11. > > Agreed, quartz and x11 variants are another problem.
They are the same problem as boost+mpi. >> It seems that you want to define variants as things that do not change >> the graph. If so, MacPorts would (and should) have to ensure that >> variant blocks don't change the dependencies (but then how to check the >> dependents of a port?). >> >> You would have a simpler definition of a variant (something that enables >> an option but doesn't change the graph) but would end up with more >> (sub)ports. > > A variant that adds a dependency on another port is not a problem. We do this > all the time. But it *does* change the graph when you do that. Which in turn makes it difficult to reproduce stability. > A variant that adds a dependency on a variant of another port is a problem, > in that it's not possible, and the require_active_variants workaround is not > ideal. The solution to this problem is to better handle the dependency graph (which is not easy). >> MPI support is definitely needed. I did not say earlier that would >> work. I said that would only work if you and MacPorts decide to get rid >> of gcc C/C++ compilers (and unify compilers-group with >> configure.compilers). >> >> I am a little worried that you glossed over the amount of work needed to >> make a general solution. There are two big choices: >> >> 1) does the MacPorts community decide to tackle variants, subports, >> graphs, etc.? >> >> 2) does the MacPorts community drop support for gcc as a C/C++ compiler? >> >> (2) is certainly less work but would also lose some advantage over other >> package managers. > > The moment OS X 10.9 came around, we basically lost the ability to > effectively use G++ (and even before then there were some issues). It's out > of our control; we're at the mercy of the C++ library Apple uses, and the > fact that G++ does not use it. That is one path, yes. Much easier than implementing what I'm talking about. What I'm looking for is a definitive "this is when MacPorts decided not to go that route," so I can link to it in the future. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
