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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
