On Jul 06, 2014, at 23:56, Mojca Miklavec wrote: >> universal_variant no > > I don't agree with this change. The "universal_variant no" is there > for ports that are not capable of being built as universal.
It was just a suggestion, but semantically speaking the expression just indicates that the port does not provide a universal variant, regardless the reason. > It would be nice to figure out why you ended up with +universal (I That's impossible, given that the information required for figuring that out is not available, and that I never noticed before I had a universal variant. Presumable because prebuild packages were available until recently, or cmake 2.8 built a few orders of magnitude faster than 3.0 does ... There are very few ports of which I installed the universal variant myself, in fact I only can think of ffmpeg (which I used in a QuickTime importer component, hence I needed the 32bit libraries). I installed MacPorts when I moved to an Intel Mac running 10.6, so I went straight from PPC to x86_64. But I must have installed 32 bit packages (other than Wine which doesn't depend on cmake). > install all dependencies as universal for example), but I don't > support disabling a variant just to prevent unintentional installation I hear you, but sometimes one has to chose The more elegant solution would probably be to improve the distinction between application and library ports. Dependencies on a standalone application are typically address-width agnostic, dependencies on libraries of course not. Question is if the amount of work (implementation and adapting existing portfiles) is worth the effort. The number of ports that are going to have to be built from source will probably continue to increase, and certain ports will likely never become 64 bits ... (It's getting late, I should wind up :) ) _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
