A PortGroup for building more 32/64-bit universal packages

[Ryan Schmidt]

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.