Universal and binary builds (was: Re: Is isysroot useful for non-universal?)

[Anders F Björklund]

Ryan Schmidt wrote:

>> Despite the fact that they cover much more than "just"
>> universal (arch) and configure (autotools), that is...
>> So it's more of a legacy quirk, than a design decision.
>
> I'm getting really burned out on universal.

It sorta worked originally, but has probably outlived itself.

Especially with the current source ports, it seems like overkill.
Had there been binary packages, then sure it might have been OK.
But when doing all the builds locally on each machine anyway ?
I personally think that "autolipo"* is neater than universal.

* i.e. when you can "add" a i386 to a ppc, and it becomes fat

> What if we set aside what we have now for universal variants and  
> spent some energy on finally doing binary builds? Finish the script  
> that builds a port in a clean MacPorts tree in a chroot. Make it  
> package that up and send it to a download server. Modify MacPorts  
> base to look for, download and install those binaries first. Make  
> those binaries integrate properly with the registry. Begin by  
> having the build server only build the default variant of a port,  
> but later it can be expanded to build more combinations of  
> variants. We can work out a system later that allows more variant  
> combinations of an old port to be built without impacting the  
> building of newly-updated ports. Since the server will have  
> multiple cores we can run multiple ports' builds simultaneously, in  
> multiple chroots.

I think this chroot build is what the MPAB project was all about.
There's also the XML/XAR based format, if anyone feels up to it...

We could also resume building RPMS, if someone wants to spend
some time on that. The build script could probably produce both
archives and packages in the same run, from the same destroot.
But the integration part with the port registry is still missing.

> I would want (at least) one build server for each OS and processor  
> combination, but if we began with just a single Intel Leopard  
> machine, that would cover the majority of users. If we add a  
> corresponding PowerPC Leopard machine, then we could do something  
> interesting: Once the Intel and PowerPC builds are sent to the  
> download server, the download server could combine both builds into  
> a single universal binary package. It would use lipo, probably  
> assisted by the code we have in the MacPorts merge procedure or the  
> muniversal portgroup. It would avoid the above problems with our  
> existing universal variants because the configure phase would run  
> once for each processor, on that processor. We wouldn't need to  
> deal with SDKs anymore. (I've never been comfortable with the idea  
> of allowing the user to specify an SDK in macports.conf, so I don't  
> see it as a problem that that would not be accommodated by our  
> binary builds.)

Or, the destroots could just be kept as separate arch archives.
If from remote, this would cut the download size in half too...

Universal binaries are mostly useful for the user, so that
there's "only one thing to choose from". If it's the computer
that is doing the choosing, it might as well pick the right one.
Maybe lipo for exporting packages, but not for internal archives.

> Using the above, we would have stable 32-bit universal binaries. We  
> would also want each build server to separately build 64-bit  
> versions. Obviously the build servers would be 64-bit machines.


It would be nice with a 64-bit option without Universal and SDKs.
In theory this just involves adding the -m64 option to the flags.

--anders