I don't believe this reply from Marcus ever made it to the list, so
I'm sending it there now with some commentary of my own.
On Jan 13, 2009, at 05:49, Marcus Calhoun-Lopez wrote:
On Jan 12, 2009, at 7:30 PM, Ryan Schmidt wrote:
Any particular reason you chose to implement it as a PortGroup?
The only reason was how quickly it could be refined, tested, and
put into use.
Ports like cairo (as you well know), 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.
Further, openssl was recently updated without maintainer approval,
so it is not guaranteed that all of that universal code still works
as intended.
Of course, just because a maintainer updates a port doesn't mean the
update is perfect. I would guess most maintainers do not try every
variant of their ports with every update, and that would include the
universal variant. Sometimes for example platform-specific patches do
not get updated (and then fail to apply on that platform) because the
maintainer did not have access to that platform.
So I see a strong need for a better merge capability.
The need is certainly there.
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.
That is the one reason I can see for having it as a portgroup -- that
portgroups can be used right away, since they're now part of the
dports tree, whereas a base change would have to wait for a new
MacPorts release before it could be incorporated into ports.
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
(perhaps even two releases if bugs are found).
By now you've committed it as a portgroup so it's out there and we
may as well try to use it in a few ports and see what happens. We can
always bring it back into base later if it works well.
My concern with it being a portgroup was whether there was any chance
that someone might want to use this merge mechanism in a port that
already used another portgroup. On the other hand, maybe every
portgroup needs to provide its own universal mechanism. Universal
builds are certainly different in the xcode portgroup for example.
I had figured we should modify the base code to offer different
universal build mechanisms, and then the "universal_variant"
boolean keyword would go away and be replaced with something more
descriptive like "universal_method" which would say how to build
universal. There should be ways to accommodate all the situations:
* port builds universal with one configure/build with multiple
arch flags (existing MacPorts way)
* port builds universal with multiple configures/builds with one
arch flag each time (your way)
* port has no architecture-specific files and is arch-agnostic
* port is broken and cannot be built universal
* (default value:) port's universal capabilities are not known;
provide a universal variant but warn that it may not work
This sounds like a good idea.
Ports like xorg-cf-files (which installs only text files) and gcc43
(which does not support universal builds) should not
be lumped together as "universal_variant no."
* port builds universal with no help (or is distributed as a
binary that is universal)
The port AquaTerm builds (ppc/i386) universal by default.
A patch is applied to keep it on a single architecture without the
universal variant.
This seems like a reasonable policy: try as much as possible to not
have universal unless asked for.
Yes... I introduced this "always universal" thing in several of my
ports, and some others, because I did not have the expertise to apply
such patches to disable the universal build.
This may be more trouble than it is worth, but lipo could be used
to "thin out" a port which is distributed as a universal binary.
Using lipo to thin a provided universal binary is an interesting idea
I hadn't considered.
We also have the need for a port to be able to indicate which
architectures it can be built for (or possibly, which
architectures it cannot be built for). This way a user could
define universal_archs to the full set of i386 ppc x86_64 ppc64 in
macports.conf and if a particular port does not work with all of
those at this time, it could specify.
So there could be a variable universal_support which could have the
values, for example,
one_processor for just 32/64 universal (the default?)
just32 for just ppc/i386 universal
full for all four architectures
These variable could then be used to construct a variable
universal_archs_supported which would be universal_archs (supplied
by the user)
pruned down based on universal_support.
I don't know that we need such abstractions as "one_processor",
"just32" or "full". I think it will suffice for the portfile to
specify either the architectures it can be built on, or the
architectures it cannot be built on (I'm not sure which of those is
better yet, though I'm leaning towards the former).
I had also wanted for MacPorts to record for which architectures a
port was built, and then for it to be able to show this in places
like "port installed". Otherwise it's confusing when you want to
upgrade a port from say a 2-way universal to a 4-way universal build.
I am not all that familiar with the registry, but this doesn't
sound too bad.
Is it just a matter of saving universal_archs_supported in the
registry using property_store?
I think you've just demonstrated that you know more about the
registry than I. :)
There are other messages in the archive where I've talked about
these topics before.
I will try to read up.
I mostly just made the same suggestions about future directions. I
don't recall there being much ensuing discussion.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
