Universal and binary builds

[Joshua Root]

Marcus Calhoun-Lopez wrote:
> Joshua Root <jmr at ...> writes:
> 
>>> Universal, however, should be limited to 32/64-bit universal as soon as
>>> possible.
>> I see no reason to limit the functionality. Changing the default archs,
>> sure.
> Granted, but the extra functionality comes with a price, especially in
> Portfile creation and maintenance.
> It also adds the problem of dependencies.
> Now, if one port depends on another, then not only must they both be
> universal, they must be the same type of universal.
> Having universal just mean 32/64-bit would greatly simplify things.
> I would respectfully suggest that the extra functionality is not worth the price.

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.

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.

>> 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.

- Josh