Universal issues

[Ryan Schmidt]

Some universal issues:


We have a disagreement about what universal means in the context of  
ports that don't install architecture-specific software. For example,  
wakeonlan installs only a perl script.

http://trac.macports.org/ticket/15516

Does universal mean "it works at full performance on all  
architectures"? In this case, ports like this that install no  
architecture-specific files should be modified to have an empty  
universal variant selected by default.

Or does universal mean "it has more than one architecture of compiled  
software"? In this case, no-arch ports should be modified to turn off  
the universal variant to indicate that a universal build of this port  
is not applicable. I believe this definition of universal has been  
used in several other no-arch ports before.

Once we decide what universal means, we need clarification on this  
point in the Guide. The Guide currently does not address the  
possibility of a port that does not install compiled software.


I proposed awhile ago that we need more fine-grained control over the  
universal variant: not just the ability to turn the default universal  
variant on and off, but if we turn it off, to indicate why we do so:  
is it because it's a no-arch port, because the universal variant does  
not work, etc. It would even be good to indicate when a universal  
build has been tested and is known to work. Also the addition of a  
second type of universal variant which employs the build-for-arch- 
arch-then-lipo strategy, instead of the build-all-at-once strategy we  
use now which is incompatible with some ports (openssl, cairo,  
probably others).

http://lists.macosforge.org/pipermail/macports-dev/2007-June/001868.html


Now we allow users to configure which architectures are included in a  
universal build. This complicates matters immensely. For example the  
wine port turns off the universal variant because it cannot be built  
universal for ppc and i386 because wine runs on Intel processors  
only. But it could possibly be built universal for i386 and x86_64.  
How can we modify port syntax to allow the one type of universal  
build but disallow the other?


Sometimes source code is not available, so we have some ports which  
install from binaries, not from source. Sometimes these binaries are  
architecture-specific, thus no universal binary is possible (e.g.  
blender, oracle-instant-client). Sometimes these binaries are  
universal, thus the ports are always universal (empty universal  
variant, enabled by default, e.g. isightcapture) -- at least that had  
been the case until we allowed users to configure the architectures.  
Now, the set of architectures requested by the user might not match  
the set of architectures provided by the binary distribution.


Many ports work fine as 2-architecture (ppc and i386) universal  
binaries but do not work as 4-architecture (ppc, i386, ppc64, x86_64)  
universal binaries (e.g. apr, and therefore everything depending on  
apr (like subversion and apache)). There is no existing syntax to  
indicate this in the port.


For the sake of ports like apr and isightcapture and others in the  
same boat, we need a way to indicate in each port which architectures  
are supported. MacPorts would by default assume that all ports can be  
built for all four architectures, but individual ports could add  
lines to change this. For example, apr could add "supported_archs  
i386 ppc" until their bug is fixed. wine could add "supported_archs  
i386 x86_64". This could solve a number of problems. 1) If the user  
requests the universal variant but the list of supported  
architectures doesn't include all the architectures the user  
requested in their universal_archs definition in macports.conf, a  
warning can be issued informing the user. 2) If a port isn't  
available at all on the user's local architecture (for example, the  
user is on ppc and tries to install wine which only supplies i386 and  
x86_64) port can issue an error and halt. Then we could eliminate  
from the portfile the code that currently checks the architecture and  
warns the user and exits.


I proposed last month that we need a way (e.g. in "port installed")  
to see for which architectures a given universal binary was built:

http://lists.macosforge.org/pipermail/macports-dev/2008-May/005314.html

When a port is installed, we need to record somewhere what  
architectures were requested. Ideally this should happen regardless  
of whether the universal variant was used or not. If it wasn't used,  
then the requested architecture is just "i386" or "ppc".


Sometimes ports build with the universal variant but don't end up  
universal. nqc currently has this problem. All the intermediary  
object files get built universal, but the final binaries end up built  
for the local architecture only due to some bug in nqc. The user is  
not informed of this and thinks he has a universal binary installed  
but in fact he does not.

http://trac.macports.org/ticket/15584

MacPorts could check the architectures in each installed Mach-O file  
to see if it matches the list of architectures requested by the user.  
If not, a warning could be issued. We may need to be a little  
selective here and not issue a fatal error at the first opportunity.  
There are some ports where mismatched architectures might be ok. For  
example, graphviz +gui installs graphviz from source but adds a GUI  
from a binary, and the GUI is PowerPC-only so far.