Universal and binary builds

[Marcus Calhoun-Lopez]

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.

> Speaking of muniversal, it would be nice if its functionality were
> integrated into base sooner rather than later, along with a more sane
> approach to universal building in general.
I agree, but I was hoping that I could create a consensus to limit the meaning
of universal to 32/64-bit.
It would make incorporating muniversal into the base easier.

> 
> 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 can not image that MacPorts ppc/i386 universal builds are in widespread
> > use.
> 
> That was the *only* kind of MacPorts universal build prior to 1.7. I
> suspect that ppc/i386 is the combination of choice for those building
> binary packages. I would go so far as to say that most people who aren't
> building ppc/i386 don't really want to build universal at all, but want
> to change the target arch (or OS, though that's an orthogonal issue).

Perhaps I was wrong about how widespread the use of ppc/i386 use was.
It just seems like ppc/i386 universal support has not made great inroads in the
Portfiles (other than being turned on by default).

-Marcus