Universal and binary builds

[Marcus Calhoun-Lopez]

Joshua Root <jmr at ...> writes:

> Once again, I don't believe that the vast majority of users really want
> universal, they are just using it as a hack to get x86_64. There may be
> a few sharing builds between an i386 and a ppc machine, but they would
> be better served by binaries.
If the vast majority of users really just want x86_64, then
it seems simplifying universal to 32/64-bit would be closer to what they want
than the mixture of 4 architectures we have now.

> Those that do need universal can reasonably be expected to know what
> they're doing, and the "price" isn't all that high anyway, since making
> this work maps exactly to a fix for #126.
When talking about "price," I was referring to maintenance of Portfiles
and base code.
Getting cross-compiling to work can be a painful undertaking
(see the patch in #17042).

> >> Also, just an observation, muniversal is not a solution that can be
> >> applied upstream. When possible, it is preferable to fix things in ways
> >> that upstream can adopt.
> > Most of the reasons muniversal is needed seem unlikely to be
> > adopted upstream.
> > For example, the configure script checking the size of an int.
> 
> I don't see why autoconf wouldn't accept a patch making their macros do
> the right thing in case of multi-word-size, or why projects using
> autoconf wouldn't accept patches to use the updated macros correctly.
Perhaps they would, but based on the ports I have checked so far,
it would be a lot of patches to a lot of projects.
In any event, the muniversal PortGroup (and the ideas which should be included
in the base code) are a good way of catching the projects where a patch is
necessary.

-Marcus