Opened 16 years ago

Closed 16 years ago

Last modified 15 years ago

#17972 closed enhancement (fixed)

RFE: Add a PortGroup with a different universal build mechanism

Reported by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 1.7.0
Keywords: Cc:
Port:

Description

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.

Attachments (1)

merge_universal-1.0.tcl (13.0 KB) - added by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) 16 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Owner: changed from macports-tickets@… to mcalhoun@…
Status: newassigned

comment:2 Changed 16 years ago by 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.

comment:3 in reply to:  2 Changed 16 years ago by 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.

Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attachment: merge_universal-1.0.tcl added

comment:4 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: assignedclosed

Fixed in r45597.

comment:5 Changed 16 years ago by 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.

comment:6 in reply to:  5 Changed 16 years ago by 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.

comment:7 Changed 15 years ago by jmroot (Joshua Root)

Component: baseports
Milestone: MacPorts Future
Note: See TracTickets for help on using tickets.