On Jan 1, 2018, at 16:25, Andrew L. Moore wrote: > Hi, > I came across the discussion of using subports as dependencies rather than > variants in MacPorts Trac #126 discussion > (https://trac.macports.org/ticket/126). > > Has splitting some ports into broad categories of subports, e.g., boost_gcc > and boost_clang, been considered or even implemented? I’m thinking that a > ${prefix}/etc/macports/subports.conf that takes precedence over variants.conf > could be helpful. > > My particular situation is that math/julia builds against gcc7, so that in > variants.conf appears: > > +gcc7 +openmpi +openblas > > But +gcc7 gets picked up when building devel/boost, and eventually > source-highlight, which depends on boost, fails to build because its Portfile > doesn't have a +gcc variant. > > A workaround is to manually build source-highlight with gcc7, add a line to > work/.macports.source-highlight.state: > > target: org.macports.build > > then finally, run port install. What I’d like to be able to do is add to a > ${prefix}/etc/macports/subports.conf something like: > > boost_clang > > which would override the variant +gcc7 in variants.conf. > > This is, admittedly, a pretty narrow use case. Just thought I’d throw it > out...
I'm having a really difficult time following this email, what problems you're experiencing and why, and how you're proposing to solve them. It is a bug that the boost port's gcc variants came back. They should be removed because they cause problems. See https://trac.macports.org/ticket/55604 The fact that a port might be a subport is an implementation detail of relevance to developers only. To users, a port is a port is a port. Ports are things the user installs explicitly, or indirectly as a dependency of another port. They're not things that are listed in a conf file. If a variant is specified in variants.conf, and a port the user installs does not have that variant, that variant is skipped and the port is installed without it; no error occurs.
