Hacking in Universal -- Don't!

[Ryan Schmidt]

On Mar 31, 2007, at 12:28, Landon Fuller wrote:

> I received a bug report about the zlib port not working -- it was  
> modified to use private API in an attempt to hack in Universal  
> support.
>
> The port, which I originally wrote in 2003, went from this:
> 	http://trac.macports.org/projects/macports/browser/trunk/dports/ 
> archivers/zlib/Portfile?rev=23414
> to this:
> 	http://trac.macports.org/projects/macports/browser/trunk/dports/ 
> archivers/zlib/Portfile?rev=22776
>
> This is not an improvement! The port is literally twice as long,  
> but more importantly, it *FAILS* on different versions of MacPorts  
> because it uses MacPorts-private undocumented API calls.
>
> I believe we need a very straight-forward policy:
> 	- Do not use undocumented, private API in Portfiles. This will  
> cause breakage and make the system entirely unmaintainable.
> 	- If making a Portfile "Universal" complicates the Portfile, then  
> you need to patch the software, not the port.

I don't want to say too much more on this topic since so much has  
already been said. But just to sum up the situation with the zlib  
port from my perspective:

There was a push for universal support. I had already figured out how  
to build zlib universal outside of MacPorts and wanted to share the  
joy, since it wasn't as straightforward as it would be with a normal  
autoconf-based package. I modified the zlib portfile locally and  
tested it to ensure that it built what I believed to be a universal  
library. I submitted a ticket [1] with a patch. Kevin Ballard, who  
clearly has more portfile experience than I, posted a much cleaner  
revised version of the patch, which also improved upon the portfile  
generally by printing status messages for the static build. He, Elias  
and I all confirmed that this produced universal libraries on our  
respective systems. (I do not know which versions of MacPorts you're  
talking about on which it did not work, but I would say that  
supporting the currently released version is enough, and to my best  
ability to test it, the patch did work on the then-current version of  
MacPorts, 1.320.) After four days, you had not responded to the  
ticket, and in fact by that time you were no longer listed as the  
maintainer of the port, since you did not update your address to a  
macports.org address by the deadline and all opendarwin.org addresses  
were deleted from all ports. Since I was interested in the port, I  
took over maintainership. You did not object or provide any feedback,  
and Elias waited an additional 11 days before committing the tested  
patch. I don't recall any tickets or emails to the lists about  
problems with this version of the zlib port.

Saying not to use undocumented private APIs is difficult for me to  
comply with, since I basically do all my portfile work by example,  
and can find no current documentation about MacPorts at all. I learn  
what functions are available by looking at other ports, and I have no  
way of knowing which of them may be public or private. (In fact I  
would say if something is supposed to be private, it should not be  
architecturally possible for it to be used from a portfile.) I  
occasionally refer to the old guide at darwinports.opendarwin.org,  
but no up-to-date version of this exists on www.macports.org. And the  
old guide doesn't tell me everything that I want to know about  
portfiles, or just mentions that some feature exists without  
explaining how to properly use it, or explains it badly.

I agree that complicated universal support in a portfile probably  
points to either missing functionality in base, or a deficiency in  
the underlying software package. But there are a lot more people who  
are willing and able to tweak portfiles than change the base code. I  
think it's ok to try things out in portfiles, to get a feel for what  
new things are needed in base. So long, of course, as this playing  
around doesn't break the port for people running the latest released  
MacPorts. And as for the underlying software, sometimes the  
developers are just unwilling to make their software compile  
universal easily. For example, the developers of cairo decline to  
make a single-pass universal compilation of cairo possible; they  
require multiple configure / make passes, one for each architecture,  
followed by lipoing everything together. As the MacPorts community  
may not be able to convince all developers of such software to make  
their compilation process universal-friendly, this is a reality that  
MacPorts may also want to provide an easy solution for.


[1] http://trac.macosforge.org/projects/macports/ticket/11438