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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
