[GSoC][Binaries support] Architecture

Bradley Giesbrecht pixilla at macports.org
Sat Mar 26 12:42:57 PDT 2011


On Mar 26, 2011, at 12:05 PM, Jordan K. Hubbard wrote:
>> *Others:
>>     *What universal binaries and multiple variants on ideas list
>> mean? I don't get the idea.
> 
> I think Anders already elaborated on this, but basically it's the question of whether or not to make packaged versions of ports with different variants set.  E.g. if a given port (let's call it sundae) has 3 variants:  +nuts, +fudge and +whipped-cream, do you build:
> 
> sundae (port with no variants and/or default variants)
> 
> Or do you build:
> 
> sundae+nuts
> sundae+fudge
> sundae+whipped-cream
> sundae+nuts+fudge
> sundae+nuts+whipped-cream
> sundae+fudge+whipped-cream
> sundae+nuts+fudge+whipped-cream
> 
> Such that the user can install any possible variation of the package?   I would argue, again, that this is a premature challenge to be taking on because of the complexity (and added build time) and, to start with, you should just build "sundae" and leave the variants as a second (or possibly never) step.

How about building ports with default variants, and binary requests for non-default variants would add a new build+variant to the build queue?
So user demand creates build variants.

>>     *The language must be TCL? Shouldn't we think about using C
>> instead in the distribution service to avoid performance issues? The
>> compiling itself might be in any language, I think, but since we
>> already have MPAB let's keep in TCL.
> 
> Now comes the hard part I've been hinting at from the very beginning.  How to actually unpack the archive "fully" on the target machine.  Let's take a relatively simple port like "ccal" as a working example.  I just built it from the port on my system and it generated the following archive file:
> 
> # xar -t -f /opt/local/var/macports/packages/darwin_10/x86_64/ccal/ccal-0.6_0.x86_64.xar 
> +COMMENT
> +CONTENTS
> +DESC
> +PORTFILE
> +STATE
> opt
> opt/local
> opt/local/bin
> opt/local/bin/ccal

Shouldn't the prefix go away?

What if a command like "port binary ccal" would fetch ccal-0.6_0.x86_64.xar, extract to ${destroot}${prefix}, skip all stages up to post-destroot and then continue. Some ports that do things before post-destroot like adduser would need to be fixed.

Does MacPorts need Developer Tools if it does not need to use compile tools? Could the MacPorts installer skip the Developer Tools test and still execute fetch, extract, post-destroot and beyond?

--
Brad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110326/314e2b0b/attachment.html>


More information about the macports-dev mailing list