On 2020-9-7 19:20 , René J.V. Bertin wrote:
> Hi,
> 
> This may be considered a "not-done" but please bear with me and give me some 
> pointers on how it might be done locally...
> 
> Suppose you have developed a Tcl function in a Portfile (or a PortGroup) that 
> performs a necessary job which you might sometimes want to be able to perform 
> outside of a `port build/destroot/install/activate` step. Exporting the Tcl 
> to a script that invokes the MacPorts interpreter via its hashbang isn't 
> hard, but the function will likely use extensions normally available only in 
> Portfiles. In particular, it might use resources defined in a PortGroup (say, 
> the Qt5 PG). 
> 
> I have already figured out in the past how to write scripts that execute in 
> the same kind of context as the `port` driver script (so I can "roll my own" 
> `port provides` or `port content`; the most useful of these scripts allows me 
> to detect activation conflicts, new files and missing ones before actually 
> upgrading to a new version).
> I haven't yet figured out how to write standalone scripts that run in 
> "Portfile context". If there's a skeleton example that shows how to do that 
> I'd love to see it.

You do it like this:
<https://github.com/macports/macports-base/blob/master/src/macports1.0/macports.tcl#L3369-L3370>

In that proc, $mport is an identifier that was returned from mportopen,
and the code being executed in the port's interpreter is 'set $key',
which could of course be replaced with any other code you want.

> Possible real-world usage: code handled in post-activate blocks seems to be 
> executed only (or reliably so) when an install preceded the activation. Just 
> testing right now with one of my ports that should be doing some significant 
> work in that phase I can confirm that it appears to be skipped entirely when 
> just activating a different installed version. Of course that's probably a 
> bug that should be fixed but the actual job performed is one I'd like to make 
> independent of the activation phase without having to reimplement it.

Activating an installed port will execute the pre/post-activate code
that was in the Portfile when it was installed, not necessarily what's
in the Portfile now.

- Josh

Reply via email to