"publishing" Tcl support functions used in Portfiles?
Joshua Root
jmr at macports.org
Mon Sep 7 12:39:50 UTC 2020
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
More information about the macports-dev
mailing list