querying arbitrary variables via `port info --var`

[Rainer Müller]

On 2015-10-23 22:20, Ryan Schmidt wrote:
> 
> On Oct 23, 2015, at 3:02 PM, René J.V. Bertin  wrote:
> 
>> I managed to extend the `port info` syntax so that it accepts `port
>> info --var foo` but of course ran into the issue that lots of
>> variables aren't known when the code is evaluated.
>> 
>> Is there a way around that? Evidently that must be the case to some
>> extent, otherwise the whole `port info --foo` feature wouldn't
>> work. But a more generic workaround, would that be possible, maybe
>> doing the double dereference in a macro/procedure that's in a
>> context where everything from $prefix to $configure.args to
>> $destroot.cmd are known?
> 
> Variables specific to phases, like configure.args and destroot.cmd,
> could theoretically (and are actually, in a few ports) be overridden
> or augmented in pre-phase blocks, like pre-configure or pre-destroot;
> MacPorts would be unable to account for such situations when
> displaying the variable for informational purposes. Other than that,
> I'd think it should be possible to display the variables. But I
> haven't seen the changes you've made to the code.

The current code of port(1) is not meant to handle arbitrary arguments.
Maybe it would be better to have some 'port dump' action for that
purpose instead?

If we would want to dump all possible options, we also would need to
keep a list when they are defined. That would be necessary to be added
in port1.0/portutil.tcl.

However, as Ryan said, the actual value of an option may change during
evaluation of phases. My approach usually includes adding a temporary
ui_debug statement to the Portfile and checking the log when testing.

Rainer