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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
