On Feb 5, 2008, at 17:21, Rainer Müller wrote:
Simon Ruderich wrote:
On Tue, Feb 05, 2008 at 11:29:37AM -0600, Ryan Schmidt wrote:
Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.
Thanks for your hint. I just added it.
As this software is just a perl script and requires no extra steps for other architectures shouldn't it considered to be already universal?
Which would be: default_variants +universal variant universal {}
I would say no. I would say "universal_variant no" is currently appropriate for software that is architecture-agnostic, like this perl script. Though I've never been really happy with "universal_variant no". It's not a Boolean situation. See my earlier message: http://lists.macosforge.org/pipermail/macports-dev/2007-June/001868.html In it, I suggest that "universal_variant" should be replaced with "universal.method" and have several possible values. Actually I don't care so much if it's renamed, but I do care that we support these options: "autoconf" (like "universal_variant yes" today) "lipo" (automated multiple building and merging with lipo [1]) "none" (like "universal_variant no" today) "implicit" (software is already universal and can't be built non- universal) "unknown" (default; same as "autoconf" (if "use_configure yes") or "lipo" (if "use_configure no") but prints a warning that this is untested) I now revise my suggestion in that "none" should be further divided into these two options: "unnecessary" (port is arch-agnostic) "impossible" (port fails when built universal) These names may not be great; suggestions for other names for these options welcomed. For example "lipo" might be better called "merge". [1] I also suggested this in an earlier message: http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001319.html