I'm hoping some other developers who have a good understanding of MacPorts base
can help me. I'm trying to understand some strange behavior of the
"option_deprecate" procedure which I think is a bug.
First, some background for those who may not be as familiar with MacPorts base.
An "option" in MacPorts—such as "depends_lib" or "configure.args"—is a variable
that can be set or overwritten without using the "set" command, that can behave
as a list, that can have items appended or deleted or replaced using the
special -append, -delete or -replace modifiers, and that supports lazy/late
evaluation. And options can have variable traces attached to them using
"option_proc" so that a particular procedure runs whenever an option is
accessed or changed or deleted.
Options are also automatically global within standard portfile code blocks,
like "build {}" or "pre-destroot {}" or "variant {}", meaning that you can just
use any option without having to first indicate that it's a global variable.
This magic occurs because standard code blocks get run through "makeuserproc"
when they're created, which automatically runs "global" on all available
globals at the beginning of each such code block:
https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=105002#L1247
However in your own non-standard code blocks, i.e. procedures defined directly
using "proc", you do have to first use "global" for any options you want to
use, and we see this in procedures in MacPorts base too.
"option_deprecate" is not used in MacPorts right at this very moment, but it
has been used before at times when we've renamed options. For example,
"livecheck.type" used to be called "livecheck.check", so for awhile, MacPorts
base used "option_deprecate livecheck.check livecheck.type" so that any ports
using "livecheck.check" would still work until maintainers got around to
updating their ports. "option_deprecate" works by creating an option with the
old name and attaching a variable trace to it using "option_proc" so that
whenever the old option is read from or written to, that action is intercepted
and redirected to the new option:
https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=105002#L260
But this doesn't appear to work right when a deprecated option is used inside a
code block.
Here's a sample portfile that works—it correctly shows that both
"livecheck.type" and "livecheck.check" have the value "default":
PortSystem 1.0
name test1
version 1.0
option_deprecate livecheck.check livecheck.type
ui_msg "livecheck.type=${livecheck.type}"
ui_msg "livecheck.check=${livecheck.check}"
But this next sample portfile doesn't work—after printing
"livecheck.type=default", it says "can't read 'livecheck.check': no such
variable":
PortSystem 1.0
name test2
version 1.0
option_deprecate livecheck.check livecheck.type
variant foo {
ui_msg "livecheck.type=${livecheck.type}"
ui_msg "livecheck.check=${livecheck.check}"
}
default_variants +foo
Obviously you wouldn't actually use "option_deprecate" inside a portfile; these
samples are just to illustrate that if an option is deprecated, then it doesn't
work right inside a code block.
It works if I add "global livecheck.check" inside the code block:
PortSystem 1.0
name test3
version 1.0
option_deprecate livecheck.check livecheck.type
variant foo {
global livecheck.check
ui_msg "livecheck.type=${livecheck.type}"
ui_msg "livecheck.check=${livecheck.check}"
}
default_variants +foo
But this shouldn't be necessary because options are supposed to be
automatically global, so I'm trying to understand how to fix this. I would like
deprecated options to behave identically to supported options.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
