[106996] trunk/base/src/macports1.0/macports.tcl

[Ryan Schmidt]

On Jun 14, 2013, at 09:32, Joshua Root <jmr at macports.org> wrote:

>> Revision: 106996
>>          https://trac.macports.org/changeset/106996
>> Author:   larryv at macports.org
>> Date:     2013-06-13 09:42:06 -0700 (Thu, 13 Jun 2013)
>> Log Message:
>> -----------
>> macports.tcl: Restore braces for variable substitions immediately followed by other substitutions.
>> 
>> The "$" looks too similar to "S".
>> 
>> See https://lists.macosforge.org/pipermail/macports-dev/2013-June/022983.html.
> 
> I guess the $/S similarity is a good point, but those aren't actually
> the ones I meant. I was referring to stuff like these:
> 
> if {[_is_valid_developer_dir "$xcode/Contents/Developer"]} {
> (reader: "can a variable name contain a slash?")
> 
> ui_error "    # malformed Xcode at $xcode, version $vers"
> (reader: "what about a comma?")
> 
> ui_warn "Failed to copy com.apple.dt.Xcode.plist to $target_dir: $result"
> (reader: "colon?")
> 
> # actually $name-${version}_$revision
> (ok, so this is a comment, but still: reader: "dash?")
> 
> set signature "$tarball.rmd160"
> ("dot?")
> 
> I know the rules, and I still have to think about it more when the
> braces aren't there.

And in fact a variable name can contain a dot. We use them all the time, like ${configure.args}, but the use of the curly braces is necessary to tell Tcl to include them in the variable name.

The style we use in most Portfiles, of always using curly braces even when they're not necessary, is pleasant and helpful, and I wish we'd do that in base as well, instead of going the other direction.