Which private API are you referring to? I know that the port was *broken* until I changed it to use the right command API, but that had nothing to do with building universal, that was a very hacky way of building the static archive. - Jordan On Mar 31, 2007, at 10:28 AM, 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.

-landonf _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

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