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. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
