RFC: Support for future compilers in base

Lawrence Velázquez larryv at macports.org
Mon Feb 18 21:27:16 PST 2013

On Feb 18, 2013, at 8:02 PM, Lawrence Velázquez <larryv at macports.org> wrote:

> I don't think return is behaving like you (or I) expect.

The following is somewhat academic, but some might find it instructive. And it will almost certainly make Jeremy hate Tcl more than he already does.

The Tcl "return" command[1] takes the form

    return [option value]* [result]?

- If you use "return", the proc just returns an empty string.
- If you use "return a", the proc returns "a". This is the common case.
- If you use "return a b", the proc again returns an empty string. It also produces a dictionary containing the key/value pair "a : b"; this dictionary can be captured by a "catch" command.
- If you use "return a b c", the proc returns "c" and produces the same dictionary as before.
- If you use "return a b c d", the proc returns an empty string and produces the dictionary "a : b, c : d".
- Ad nauseam. Some options, like "-code", are treated specially by Tcl.

Also note that Tcl does not evaluate expressions unless explicitly asked to. The "if", "while", and "for" commands evaluate their conditionals (but not their bodies); there may be other examples. Otherwise, you're on your own. (NB: Expression evaluation is distinct from variable and command substitution.)

Now we see what compiler_is_port actually does.

> proc portconfigure::compiler_is_port {compiler} {
>     return [portconfigure::compiler_port_name ${compiler}] != ""
> }

The compiler_port_name command is substituted, and its return value becomes a key in the results dictionary with the associated value "!=". The proc *always* returns the empty string. Similar issues would have come up with arch_flag_supported.

The boolean expressions must be explicitly evaluated with "expr"; I committed this in r103219.

Whoo, Tcl!


    [1] http://www.tcl.tk/man/tcl8.5/TclCmd/return.htm

More information about the macports-dev mailing list