[87310] trunk/dports/_resources/port1.0/group/php5pear-1.0.tcl

[Ryan Schmidt]

On Nov 16, 2011, at 19:06, Bradley Giesbrecht wrote:

> On Nov 16, 2011, at 4:42 PM, Ryan Schmidt wrote:
> 
>> On Nov 16, 2011, at 16:54, pixilla at macports.org wrote:
>> 
>>> Revision: 87310
>>>        http://trac.macports.org/changeset/87310
>> With this commit it looks like you've gone to a 2-space-per-indent style from our usual 4-space-per-indent. Ok, but you should add our standard modeline, with the instances of 4 changed to 2. This will help some editors understand that this is the style you want to use.
> 
> No wonder, the missing mode line changed my indenting. I'll clean that up. Is documentation for "our standard modeline"?

The standard modeline is here:

http://guide.macports.org/#development.creating-portfile

And more detail here:

http://guide.macports.org/#development.practices.portstyle

The documentation says "portfiles" but I would take that as applying to any MacPorts source file.


>>> +  depends_lib         path:bin/phpize:php5 port:php5-pear
>> 
>> Heads-up: once there are separate php54 php53 php52 ports as I'm planing, something different will have to happen here, since there will no longer be any port providing "phpize" (or "php").
> 
> And I thought I was being smart. Oh, no phpize because it will be phpize54?

Right. php54, phpize54, php-fcgi54, and so on.


>>> +    system "${php5pear.cmd-pre} ${php5pear.cmd-pear} ${php5pear.cmd-post} config-show"
>> 
>> This kind of stuff looks like you *may* want to investigate the MacPorts base "command" system. configure, build, destroot, etc. are all "commands" in MacPorts, each of which has pre_args, args, post_args, env, as you know. You can probably create your own commands and run them with "command_exec". That *might* clean up some of this code, at least reduce some of the redundancy. (Or it might introduce its own complications. :)) An example of running commands with command_exec (though not creating entire new commands) is in the current php5 port (though it will go away in the New PHP Order, coming soon to a MacPorts near you).
> 
> Sounds interesting. It would be nice to make the PortGroup file easier to read. I suspect there are some unused vars and I am not really clear on tcl variable scope.
> For instance, does a dot in a name have special meaning?

Right, you asked me that privately and I forgot to respond. I don't actually know. Conceptually, it creates a namespace; we think of e.g. "php5pear.channel" as belonging to the php5pear namespace. This is to avoid collisions with variables that might be defined in ports or in other portgroups. We have an informal agreement that only the php5pear portgroup would define variables or procedures beginning with "php5pear." But whether the "." in the name has any special significance to the Tcl language I don't know.


>>> +    # Remove all invisible "dot" files.
>>> +    fs-traverse -ignoreErrors item "${destroot}${php5pear.instpath}" {
>>> +      if {[string first . [file tail ${item}] 0] == 0} {
>>> +        # Using system rm because I could not find a way to delete dot files with [file delete].
>>> +        system "rm -R ${item}"
>>> +      }
>>>   }
>> 
>> Curious: what problems did you run into with [file delete]?
> 
> IIRC I could not delete dot files with "delete" or "file delete". I also wanted to glob the dot files and I could not find a tcl command to do so. My tcl is weak so any help would be awesome.

I would think glob would work fine, though, as in the shell, expanding "*" will not include dot files. If you want them, you have no explicitly say so, by using ".*"

It should just be (untested):

    fs-traverse -ignoreErrors item "${destroot}${php5pear.instpath}" {
      if {[string first . [file tail ${item}] 0] == 0} {
        if {[file tail ${item}] != "." && [file tail ${item}] != ".."} {
          delete ${item}
        }
      }

Though [delete] and [file delete] probably only delete files, not directories. If there are dot directories you're trying to delete, then....... I don't know if we have a recursive delete proc somewhere in base already.


>> Note that traversing and looking for items starting with "." will of course find the directory entries "." and "..", which you cannot remove, and which I'd suspect [file delete] would complain about. "rm" should complain too, but it might just be a warning that you never see. Note also that you can shorten [file delete] to just [delete].
> 
> Maybe that is why "delete" did not work. I'll try again.