Callback registration mechanism

Rainer Müller raimue at macports.org
Wed Feb 13 14:42:54 PST 2013


On 2013-02-12 02:49, Clemens Lang wrote:
> On Tue, Feb 12, 2013 at 12:28:08AM +0100, Rainer Müller wrote:
>> 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.
> 
> Yes, I am aware of the issue. If a callback changes something that would
> require another round of callbacks to be run, that doesn't work.
> However, if everybody writing these callbacks is aware of this, it
> shouldn't be a problem.
> 
> This is also the reason why I wouldn't declare this a public API.

Okay.

>> 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.
> 
> What's the benefit of doing this? It seems a lot more complex to me than
> what we currently have, but maybe I'm just not seeing the beauty of this
> yet.

Well, there's not much beauty to find in portutil...

I don't think it would be more complex. Currently, callbacks are
registered from the global scope somewhere in the file. This means they
are registered in the order the different targets are parsed - which
makes them kind of dependent on the target they are defined in.

The correct place to list the callbacks for this target is in the target
definition and not somewhere below in the file between other proc
definitions.

Rainer


More information about the macports-dev mailing list