Something occurred to me. I recently added livecheck to all my ports. For those who (like me until a little while ago) hadn't quite grasped what livecheck does, it lets you type (the rather unwieldy) "port echo maintainer:yourname | sudo xargs -n 1 port livecheck" and see which of your ports have new versions available, so that you know which ones you need to update. And livecheck has a number of different ways it can check for this. It can check sourceforge or freshmeat, or whether a regex matches the contents of a web page, or whether a distfile is newer than the portfile. It uses reasonable defaults but often needs help. For some ports, like expat, livecheck already worked just fine -- expat already downloaded from sourceforge, and the sourceforge livecheck worked correctly. I added "livecheck.check sourceforge" anyway, to remind myself that I had checked the livecheck functionality and that it worked properly. For other ports, like sleepwatcher, I had to set it up to check the project's homepage with "livecheck.check regex". For one project, tidy, I even turned livecheck off with "livecheck.check none", since I couldn't figure out a way to do it, and also since the project hasn't released a tarball in years. Now take a look at the situation we have with universal binaries in MacPorts. Currently, all ports automatically get the default universal variant, but it doesn't work for all ports. Some ports, like libid3tag, seem to build fine, but then the end result isn't universal after all. Others, like cairo, will complain during the configuration phase (and will need a build-twice-and-lipo approach to build correctly). Still others, like pdftk, don't use autoconf, which the default universal variant requires. Finally, ports like minivmac don't need any help building universal at all, because their Xcode project files already take care of it. What if we used a similar syntax to the one we use for livecheck to describe a port's universal abilities? Let me see if I can remember what our current syntax for universal functionality looks like... - The default universal variant shows up automatically. - If the software can't build universal (at least not yet), then you're supposed to add "universal_variant no" to the portfile. - If the software builds universal all by itself, I've been saying "default_variants +universal" and then "variant universal {}" (The point is that "port installed foo" would show the +universal variant, letting the user know that it is, in fact, universal.) - If you want different universal build behavior, you override the universal variant. What if we changed it like this... - There's a new variable "universal.method" (universal's analog of "livecheck.check") which has several possible values, described next. - "universal.method autoconf" is the current all-at-once "-arch ppc - arch i386" method suitable for many autoconf-based projects. - "universal.method lipo" would be a new universal method which causes the port to automatically configure and build multiple times, once for each architecture, and then have the result stuck together with lipo at the end, much like (or possibly even using) the "unify" script from the Mozilla project that I talked about on this list some months ago. - "universal.method none" would replace the current "universal_variant no" syntax. I don't know if "universal_variant no" currently does this, but it might be nice, if you tried to "port install +universal" such a port, if it would print out a message advising that universal won't work. Also, "universal" should not show up in "port info" and "port variants" for such ports. - "universal.method implicit" would correspond to the "don't mind me, I'm already universal" disposition. - The default value would be "universal.method unknown" which is the same as "universal.method autoconf" but prints a warning that universal functionality has not been verified for that port, possibly inviting the maintainer to set "universal.method autoconf" if it is found to work properly. - Addendum to the preceding: "universal.method unknown" would correspond to "universal.method none" if the port says "use_configure no". We shouldn't advertise a universal variant if we can already determine it won't work. - Another addendum: alternately, if the port says "use_configure no", "universal.method unknown" could correspond to "universal.method lipo", but again with the warning that it might not work. Comments on this syntax or the new functionality it implies? While researching for this email I discovered (or possibly rediscovered; I forget) the functions lipo() and backup() in portutil.tcl... I believe these are only used by the openssl port, and it is my hope that the implied new code in MacPorts base for "universal.method lipo" would be able to handle openssl, cairo and similar ports automatically.