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