No subject

That same approach will see ports for native OS X apps put their stuff into locations like ${prefix}/Library/Frameworks, as one would expect.

It's probably fine to tune the layout to adhere to guidelines like "cmake files should go under ${prefix}/share/cmake/Modules", but to what extent does one have to accept having to patch unknown numbers of dependent ports in order to comply with such guidelines?
Case in point: port:automoc which was modified (more or less) recently; I'm not yet convinced that only a few ports need patching to comply with that "fix" (and at least port:polkit-qt has not been "fixed" so it builds again as of this moment).

What really inspired this email though is what's happening with the Qt ports, with the underlying question: is there anything in MacPorts guidelines/conventions/etc that advises, dictates, dis-advises or forbids putting all of Qt under a single version-specific prefix?
Or idem re: the approach I have been following, one that maintains the current Qt layout as much as possible.

As many of you know, I've been working since december 2014 to make Qt4 and Qt5 co-installable (concurrent). I took that task upon me because I had need for it (and the time and experience) and because the official maintainers didn't have the time (for another 6-9 months; actually, one was MIA for so long I almost filed a request to take over the Qt5 port).
After some experimenting I concluded that it was best to make only minimal changes to the existing installation layout, moving only those components that made concurrent installation impossible. Everything Qt under ${prefix}/share was already installed under qt4 and qt5 directories, like it is on Linux/Freedesktop/XDG platforms (in reality the whole resulting layout is comparable to what's usual on Linux). In fact I ran into issues with an approach that seemed easier, putting all of Qt4 into its own ${prefix}/libexec/qt4 prefix. I didn't record exactly what kind of issues they were, but in hindsight it seems evident that software coming from a Qt-based Freedesktop/XDG environment (like all KDE ports) expects shared resources in locations like ${prefix}/share, and that those are at least in part runtime rather than linker dependencies.
Keeping ${prefix}/share/qtN, ${prefix}/share/doc/qtN etc. locations also avoids duplicating directory structures (no additional ${prefix}/libexec/qtN/share), which I consider an advantage as someone often digging for files from a commandline.

For pure Qt applications that aim to behave like native apps there shouldn't be a difference. Many of those will build be default as self-contained app bundles (copying Qt resources from wherever they're stored). In that operation mode, having a single Qt install dir has advantages, but that directory isn't specifically intended to be a central repository of shared runtime resources and libraries. And from what I've seen it is accepted behaviour in the corresponding ports to disassemble the app bundle or to patch the build system, in order to force the use of shared resources rather than private copies.
In other words, arguments like "this is how Qt installs on OS X" aren't relevant for MacPorts (at least in my understanding).

A few final words because this message is already way longer than intended:
I have been running the minimal-change concurrent Qt4 layout since late December 2014, with a trivially simple variant that puts symlinks to the Qt framework bundles in their old locations and that removed the need to rebuild all dependent ports at once, and have had equivalent Qt5 ports in place for only slightly less time. I have had to change only a handful (<5) ports to comply with the new layout, and those only because the Portfiles used hardcoded locations rather than variables from the PortGroup, or added explicit dependencies to port:qt4-mac.
In other words, I've been able to hot-swap the mainstream/official port and my own which has been helpful a few times.

BR,
R.