On Mar 3, 2007, at 2:33 PM, Jordan K. Hubbard wrote:
On Mar 3, 2007, at 1:09 PM, Landon Fuller wrote:
I agree. It's not that universal builds are a bad idea; it's that supporting universal software requires serious bastardization of Portfiles in most cases. Assuming we implement some sort of binary distribution, I'd personally much rather use the approach that fkr and shantonu used for supporting Darwin x86 and PowerPC -- build the software on each system, natively, and then join the resultant RPMs into a single fat RPM.
I think this may have gotten lost in all my earlier verbiage, but I also pointed out early in the conversation that there are many many open source projects building universal at Apple without such "bastardization". The Makefile for OpenSSL is just 147 lines, for example, and of that at LEAST 50% has to do strictly with Apple's own requirements (the whole SRCROOT and DSTROOT thing, order files, all the things you probably still have nightmares about from time to time). Perhaps 5 lines in the Makefile are devoted to the fact that it's building universal.
I don't think it's reasonable to compare Apple's static manually managed B&I build system to MacPorts. We could also write shell scripts and Makefiles and random glue to build software, but we don't -- MacPorts, instead, requires ports to be declarative, and then takes care of the rest. These are two different problem spaces. Apple, due to B&I's requirements, *needs* software to build universal on single systems. We don't, and there are arguably many benefits to not doing so, the greatest of which is reduced maintenance and implementation complexity.
Why is everyone being so quick to slam pipping's changes before they even have a chance to go through an evolution or two? I know there are still a few people here who still don't get the whole point of universal builds, or doubt their value to MacPorts, but that's orthogonal to the whole issue of "quality of implementation", something which has to at least be given a chance to improve before coming to any firm conclusions about it.
Because the right place to fix this is in the upstream project's build, not as an add-on set of extensive hacks. It's admittedly not black and white -- if a project builds universal with a few CFLAG tweaks, and works fine under testing, then super! But blithely forcing software into the +universal universe just doesn't add up when there are only fringe benefits and *great cost* in terms of added complexity. -landonf