[Bulk] Re: [Bulk] Re: [Bulk] Snow Leopard +universal necessity
Jann Röder
roederja at ethz.ch
Sat Sep 5 16:51:50 PDT 2009
Two more reasons for being in favor of the default universal variant for
i386 and x86_64:
1. Apple also does it. They even include the ppc code even though snow
leopard doesn't even run on ppc anymore... so maybe they do it to
support cross compilation.
2. The eiffelstudio port would also benefit from 32bit libraries since a
32bit development environment is needed in case you want to build 32bit
binaries.
Jann
William Davis schrieb:
>
> On Sep 2, 2009, at 5:31 PM, Joshua Root wrote:
>
>> On 2009-9-3 03:35, William Davis wrote:
>>> It just seems simpler to me to have port rebuild
>>> dependents as universal whenever that was needed instead of building
>>> them all universal, whether needed or not.
>>
>> Well of course that's simpler for you, but it's not simpler for whoever
>> has to implement that feature! ;-)
>
> Yes, well, there is that aspect of it! I'm very conscious of all the
> work Ryan does around here, and didn't mean to sound unappreciative.
>
>
>
>> There is already a ticket open for this feature request:
>> <http://trac.macports.org/ticket/20739>
>>
>> As you can see, Ryan is well aware of it. I believe he has been
>> discussing what we can do in the meantime to mitigate these issues, not
>> saying that these interim measures would be the ideal solution.
>
> I do see that he wasn't proposing +universal as a permanent fix .
>
>> My initial thought is that ports that can only be built for limited
>> architectures should be checking the archs of their dependencies and
>> giving an informative error message if they are not what's needed.
>>
>> - Josh
>
> To me that seems the preferable temp fix, but of course the person doing
> the work should have the greatest weight.
>
> William Davis
> frstanATbellsouthDOTnet
> Mac OS X ver 10.6 Darwin 10.6
> XQuartz 2.3.4 (xorg-server 1.4.2-apple45)
> Mac Mini Intel Duo @ 1.86 GHz
>
> Mundus vult decepi, ego non
>
More information about the macports-dev
mailing list