universal syntax like livecheck?

Ryan Schmidt ryandesign at macports.org
Thu Jun 14 00:09:49 PDT 2007


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.





More information about the macports-dev mailing list