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. > 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. 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. >>>>> It is understandable to not want to implement the greater complexity. >>>>> Your proposal is to get rid of gcc for compiling C/C++. If that's the >>>>> direction MacPorts wants to go, then I'd request that it be uniform: no >>>>> port has any variant to change the C/C++ compilers. >>>> >>>> As I understand it, it is indeed our goal for ports not to have variants >>>> that change the C/C++ compilers. However, many ports have gcc variants >>>> from years ago before we fully understood the C++ standard library >>>> mismatch issues and they have not been updated. For each port that has >>>> compiler variants, we would need to examine them to see why they do that, >>>> and how to safely remove them. >>> >>> The thorny ports (perhaps more) will be ATLAS and boost. A good place to >>> start would be to simplify the ports that use the compilers port group >>> and refactor that to make it use the configure.compiler logic. After >>> that, there are approximately 118 ports that use gcc as a compiler. >> >> Yes, atlas has a bunch of compiler variants. I would love for most or all of >> them to go away. But part of atlas needs fortran so it needs to deal with >> that at least. > > I would love for fortran to go away, too, but certain packages will need > different compilers. > >> I already "fixed" boost by removing the use of the mpi portgroup. If mpi >> support needs to be brought back, then a general solution needs to be found >> for the mpi portgroup, which based on what you said earlier might be as >> simple as deferring its work until the pre-configure block. > > 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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
