cross-port ${filespath} access?

[René J.V. Bertin]

On Tuesday April 14 2015 17:51:13 Clemens Lang wrote:
Hi

>would slow down trace mode considerably, but it's a bug. You should not rely
>on this behaviour, because it will go away once caching is implemented so the

Well, as I said I only use this as an admittedly rather dirty hack for quick testing of variations of my port (not to be confounded with port variants).

>lstat(2) for every path component is no longer required. And I'm not doing
>that to break your use case, but to fix weird behaviour of certain ports in
>trace mode (e.g. Qt stuff uses a lot of directory symlinks that are affected
>by this and are currently considered files MacPorts doesn't know about, which
>is wrong).

Erm, you may have noticed that I've been spending a lot of time working on the Qt ports, so if those symlinks are created by qt4-mac or qt5-mac they do kind of relate to my use cases :)
I think I did run into an issue with a directory symlink earlier today. The install phase aborted because it found an existing symlink that "wasn't part of any port" while a priori it was. In this case, it was probably created by port:QtCurve in order to expose the style plugin (that gets installed in KDE's plugin directory) to pure Qt applications.
Would it be better if the port:qtN-mac created an empty directory instead of that symlink and the style port (QtCurve) created a symlink to the actual plugin rather than to the plugin directory?

R.