Callback registration mechanism (was: Re: [102932] trunk/base/src)
Rainer Müller
raimue at macports.org
Mon Feb 11 15:28:08 PST 2013
On 2013-02-11 03:01, cal at macports.org wrote:
> Revision: 102932
> https://trac.macports.org/changeset/102932
> Author: cal at macports.org
> Date: 2013-02-10 18:01:56 -0800 (Sun, 10 Feb 2013)
> Log Message:
> -----------
> Automatically add dependency on MacPorts-provided compilers, if chosen as configure.compiler. Closes #32542.
>
> This also adds a generic machanism to register callbacks to be run after
> sourcing the Portfile and evaluating the variants. This callback
> mechanism can probably be used to simplify other parts of port1.0, e.g.
> automatically adding a dependency on autoconf when use_autoreconf is set
> to yes, automatically adding a dependency on bsdmake when build.type is
> bsd, etc.
I like the idea, but I also have some bad feelings with this. The
callbacks are run after the Portfile is evaluated, so the end result
cannot be influenced or overridden anymore. However, I don't see any
practical problems with it yet.
(more below)
> For ports that blacklist all Xcode-provided compilers using
> compiler.blacklist (so a fallback from MacPorts is used) the dependency
> information recoded in the PortIndex will be missing these automatic
> dependencies, because the PortIndex is usually generated on a server
> without Xcode.
>
> Modified Paths:
> --------------
> trunk/base/src/macports1.0/macports.tcl
> trunk/base/src/port1.0/port.tcl
> trunk/base/src/port1.0/portconfigure.tcl
>
> Modified: trunk/base/src/macports1.0/macports.tcl
> ===================================================================
> --- trunk/base/src/macports1.0/macports.tcl 2013-02-11 02:01:51 UTC (rev 102931)
> +++ trunk/base/src/macports1.0/macports.tcl 2013-02-11 02:01:56 UTC (rev 102932)
> @@ -1617,6 +1617,8 @@
> error "Error evaluating variants"
> }
>
> + $workername eval port::run_callbacks
> +
> ditem_key $mport provides [$workername eval return \$subport]
>
> return $mport
>
> Modified: trunk/base/src/port1.0/port.tcl
> ===================================================================
> --- trunk/base/src/port1.0/port.tcl 2013-02-11 02:01:51 UTC (rev 102931)
> +++ trunk/base/src/port1.0/port.tcl 2013-02-11 02:01:56 UTC (rev 102932)
> @@ -32,6 +32,33 @@
> # standard package load
> package provide port 1.0
>
> +# Provide a callback registration mechanism for port subpackages. This needs to
> +# be done _before_ loading the subpackages.
> +namespace eval port {
> + variable _callback_list [list]
> +
> + # Append a new procedure to a list of callbacks to be called when
> + # port::run_callbacks is called from macports1.0 after evaluating
> + # a Portfile
> + proc register_callback {callback} {
> + variable _callback_list
> + lappend _callback_list ${callback}
> + }
> +
> + # Run the callbacks registered in the callback list. Called from
> + # macports1.0 in the child interpreter after evaluating the Portfile and
> + # the variants. Clears the list of callbacks.
> + proc run_callbacks {} {
> + variable _callback_list
> + foreach callback ${_callback_list} {
> + ui_debug "Running callback ${callback}"
> + ${callback}
> + ui_debug "Finished running callback ${callback}"
> + }
> + set _callback_list [list]
> + }
> +}
> +
I think this could be integrated with the existing target_*
infrastructure. The callbacks would be registered from global scope
using a new proc target_callbacks into the ditem and then some helper
proc targets_run_callbacks would be called from macports1.0.
Unless, of course, you have plans to also use these callbacks from
Portfiles itself or from port groups. In which case it would not make
sense to limit this to targets only.
Rainer
More information about the macports-dev
mailing list