#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)
Change History (8)
comment:1 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Owner: | changed from macports-tickets@… to mcalhoun@… |
---|---|
Status: | new → assigned |
comment:2 follow-up: 3 Changed 16 years ago by blb@…
comment:3 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: | assigned → closed |
Fixed in r45597.
comment:5 follow-up: 6 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 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: | base → ports |
---|---|
Milestone: | MacPorts Future |
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.