Thank you and thank you again. This is so very helpful.
On Nov 16, 2011, at 6:55 PM, Ryan Schmidt wrote:
> On Nov 16, 2011, at 20:02, Bradley Giesbrecht wrote:
>
>> On Nov 16, 2011, at 5:49 PM, Ryan Schmidt wrote:
>>
>> So is declaring an "option" something like a shorthand so you don't have to
>> use "set" to set or change a var value?
>
> options are like global variables you don't have to use "set" to set, but
> they're more than that. For example, they get -append and -delete procs added
> to them. configure.args, depends_lib, etc. are all options. So just like you
> have configure.args-append, by declaring e.g. php5pear.channel as an option,
> you now have the procedures php5pear.channel-append and
> php5pear.channel-delete available. These procs might not make sense for every
> one of your options, but they're there nonetheless if you want them.
>
> The most important difference between variables and options though is that
> options are evaluated lazily. This means an option's default is not evaluated
> when it's declared; it's evaluated when it's first used. You're already
> familiar with this behavior from many of the options in MacPorts base.
> Consider these MacPorts options and their default values:
>
> default distname {${name}-${version}}
> default worksrcdir {$distname}
>
> This code executes the moment the parser hits the line "PortSystem 1.0" at
> the top of a portfile. name and version haven't been defined yet, but that's
> fine; MacPorts has just set up distname so that, the first time something
> tries to use its value, it'll figure out what name and version are then. Same
> with worksrcdir: it's set up so that the first time it's read, it'll take the
> current value of distname. In many ports, you'll change distname, and then
> expect worksrcdir to have changed along with it. And this works, because you
> hadn't tried to read worksrcdir until after you set distname.
>
> Example from the php5extension portgroup:
>
> options php5extension.extension_dir
> default php5extension.extension_dir {[exec ${prefix}/bin/php-config
> --extension-dir 2>/dev/null]}
>
> If that [exec] were evaluated the instant the parser reached the "PortGroup
> php5extension 1.0" line in the portfile, that would cause an error if the
> user hadn't installed the php5 port yet, which provides the php-config
> executable. Instead, that [exec] is not run until
> ${php5extension.extension_dir} is first read (which, looking further into the
> portgroup, is in a pre-configure block, which won't run until after the php5
> port is already installed).
>
> That's what the extra set of curly braces surrounding the default are, by the
> way. If those weren't there, it would be evaluated immediately.
>
>
>> Now I think I know how to accomplish this, where I want to change a var to
>> non-default if the Portfile passed in an arg:
>> option php5pear.channel
>> option php5pear.packagexml
>> proc php5pear.setup {package.name package.version {package.channel
>> "pear.php.net"} {package.packagexml "package.xml"}}
>> php5pear.channel ${package.channel}
>> php5pear.packagexml ${package.packagexml}
>
> First, remember it's "options", not "option". Then, I assume you meant those
> assignments to be inside the proc:
>
> options php5pear.channel
> options php5pear.packagexml
> proc php5pear.setup {package.name package.version {package.channel
> "pear.php.net"} {package.packagexml "package.xml"}} {
> php5pear.channel ${package.channel}
> php5pear.packagexml ${package.packagexml}
> ....
> }
>
> Yes, you could do that. The only problem is you've decided that not only does
> the namespace "php5pear" belong to your portgroup, but also "package". Yes
> they're in fact local variables in this proc.... but I don't think we've used
> variables whose names contain a dot in this manner before. They've always
> been top-level global entities, and the part before the dot is there to
> create a pseudo-namespace, to ensure there's no ambiguity. Long story short,
> I'd just use "normal" variable names for proc arguments. Using an underscore
> instead of a dot would be fine for example.
>
> proc php5pear.setup {package_name package_version {package_channel
> "pear.php.net"} {package_packagexml "package.xml"}} {
> ....
> }
>
> In the setup proc, I'd only put the most essential parameters. name, version,
> channel is probably necessary. What about package.xml? None of the 500+ pear
> ports you added so far use it, unless I did my grep wrong. If the odd port
> here or there needs to override the package.xml, I'd just let that port set
> that option directly, as in:
> PortSystem 1.0
> PortGroup php5pear 1.0
>
> php5pear.setup foo 1.2.3 channel.example.com
> php5pear.packagexml otherpackage.xml
Perfect.
> And the portgroup would define the default value, as in:
>
> options php5pear.packagexml
> default php5pear.packagexml package.xml
Thank you sir!
Regards,
Bradley Giesbrecht (pixilla)
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
