RFE: Add a PortGroup with a different universal build mechanism

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

To facilitate the building of more 32/64-bit universal binaries,
I would like to propose a PortGroup which builds the packages
separately and then merges them together.

It is intended to be an improvement of the ​merge function.

[blb@…]

Shouldn't this really be either used to improve proc merge or be another proc, instead of being a portgroup? Though being a port group does mean it can be added/updated without new MacPorts releases.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to blb@…:

Shouldn't this really be either used to improve proc merge or be another proc, instead of being a portgroup? Though being a port group does mean it can be added/updated without new MacPorts releases.

As you say, the only reason was how quickly it could be refined, tested, and put into use.

Ports like cairo, openssl, and fftw-3 spend a fair amount of code trying to support universal builds.
Their support is a little fragile due to the need to merge header files.
So I see a strong need for a better merge capability.

So far, I have only used merge_universal-1.0.tcl to build universal versions of gmp, libffi, and mpfr.
No doubt further features are needed to be of general use.
Using a PortGroup would allow faster refinement.

As a side note, mpfr built using both universal mechanisms (-arch ... -arch ... and merging), but they produced different binaries
due to a variable HAVE_LDOUBLE_IEEE_EXT_LITTLE.

Perhaps it is bad policy to use a PortGroup this way, but it seemed better than waiting for the next version release.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Fixed in r45597.

[blb@…]

Can the portgroup be merged into trunk now, I see the group itself hasn't had updates in a couple of weeks and the list of ports using it is increasing? Then we could also merge to the 1.7 branch and cut a 1.7.2 so it gets added quickly.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to blb@…:

Can the portgroup be merged into trunk now, I see the group itself hasn't had updates in a couple of weeks and the list of ports using it is increasing? Then we could also merge to the 1.7 branch and cut a 1.7.2 so it gets added quickly.

Unfortunately, it can not be merged into the trunk because I have not gotten it to work correctly within the base code.
I continue to work on it, and as soon as it is minimally functional, I will submit it.

The reason the list continues to grow is because I or one of my colleagues wanted a 32/64-bit universal of a library (or dependency) for our work.
As I get them to work, I have been committing the results.
If this is causing any type of problem, please let me know.