[49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

[Marcus Calhoun-Lopez]

Ryan Schmidt <ryandesign at ...> writes:

> 
> I still think rather than devote a lot of energy to this mechanism,  
> we should instead focus on building binaries, and let the server  
> merge them together -- or even let the user download both the powerpc  
> and intel binaries and have the user's macports merge them. Either  
> way, we wouldn't have to worry about figuring out how to let the  
> phases run multiple times, because the server would just run "port  
> install" multiple times instead.
> 

I think binaries would be great idea.
There would not be much reason for intel/ppc universals
anymore because the user could simply download the correct architecture.

My particular interest is 32/64-bit universals.
Simply letting the user or server merge the 32 and 64 bit versions would
be a bit of a problem.
Some ports require tweaking for the merge to work.
Big and complicated ports like qt4-mac and python2.6 probably would not
merge easily.
Fortunately both packages support universal builds.

We could have separate prefix values for 32 and 64 bit libraries and
forget universals.
Once built, however, universal libraries are very convenient.
Plus, I like the idea that all I need to do is build my a.out program
once and run:
time arch -arch i386 ./a.out
time arch -arch x86_64 ./a.out
to compare 32-bit and 64-bit execution.

If we want to support 32/64-bit universals, it seems to me that
incorporating muniversal into the base is a good way to accomplish it.

-Marcus