Just say no to +universal
landonf at macports.org
Sat Mar 3 14:56:16 PST 2007
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/0dfc38f4/PGP.bin
More information about the macports-dev