build glib2 universal binary on PPC

[Elias Pipping]

that's why i added a link to this paste in my mail ;)

    http://paste.lisp.org/display/37714,1/raw

assuming nothing in the very core of macports is touched (so there's  
nothing like "build1, build2" or anything) this is what's reusable:

  * the backup function that is passed an architecture and works on a  
filelist
  * the invocation 'build - backup' (goes into pre-build, post-build)

so... what's the actual difference between these ports (that use lipo  
to build universal) is:

  * the step that modifies the configuration for each architecture  
before building
  * the file list

the problem with the file list is: in order to allow creating it  
through globbing instead of having a static list for every port it  
would have to be created between the build- and the backup-step.

because the post-configure step needs to be done twice and we have  
something like

variable - constant - variable - constant

the post-configure step of the second build phase needs to go into  
'build'

so it's basically:

variable: post-configure {foo - whatever needs to be done for the  
first run}
constant: pre-build (comes from the groupfile)
variable: build {bar - whatever needs to be done for the second run}
constant: post-build (comes from the groupfile, too)

in order to allow splitting up the build- and the backup-step for the  
filelist that would require the invocation of the backup step to go  
into build, instead of pre-build (not a problem) and post-post-build  
(there's no such thing, is there?). since after post-build comes pre- 
destroot and such a step shouldn't go into the destroot step that'd  
require restructuring of the whole configure-build-destroot idea with  
pre- and post-. so umm... what do we do?


Regards,

Elias Pipping


On Mar 6, 2007, at 8:00 AM, Ryan Schmidt wrote:

>
> On Mar 6, 2007, at 00:00, Elias Pipping wrote:
>
>> I hate to break it to you but I guess glib2 will have to go to the  
>> same steps as openssl:
>
> I have to agree with the earlier post in another thread that the  
> openssl port has become quite a mess with this universal stuff, and  
> I think it would be wiser if no other ports copied that code.  
> Copying code means you've missed a chance for creating a reusable  
> function. Someone who understands all of what was written in the  
> openssl port (and I don't, because I just glanced at it) should  
> figure out how to make useful reusable functions that can be  
> incorporated into the base of MacPorts, rather than duplicate most  
> of it in several other ports, each time making ultimate cleanup of  
> the situation more involved.
>