All KDE ports need a major revbump, due to recent changes to qt4-mac

[René J. V. Bertin]

Ohoh, so this is finally where I get to say "I told you so"?

@Michael Dickens wrote:

> qtscriptgenerator is having issues with locating phonon now that it's
> not co-located with the qt4 install. Like QCA, it might make sense to
> just co-locate phonon into the new qt4 install prefix.

Yeah, and while ye-all are at it, why not co-locate everything that depends on 
Qt4 in the new qt4 prefix?

In other words: "le monde à l'envers"

@Craig wrote
> Something I wondered about was the choice of ${prefix}/libexec/blah

Quite a few ports ("base" and llvm/clang included) use libexec as prefix-in-a-
prefix. When I proposed libexec/qt4 and libexec/qt5 (sic) way back,it seemed more 
in line with existing practice to abuse the libexec directory than the lib 
directory. After all, libexec can be read as "lib[s] plus exec[s]", which is 
exactly the case *for my install layout*.

@Mojca wrote:
> In my opinion it is also *much* better if CMake and pkg-config files
> end up where they are supposed to be.

Yep. With CMake it's less clear what exactly that place, since there are several 
locations that are used (and not each by a single port). But in any case, I 
think it's safest not to change such locations from what the port intends (and 
other ports/packages will expect) if it is not to use a central location 
instead.

> (There are also many other files
> like "libexec/qt4/share/doc" that could easily be in "share/doc/qt4/"
> etc, even though those are not as critical.)

Of course. There was never a reason to move those in the 1st place, and that 
includes share/qtN/* (which includes mkspecs and plugins).

I also don't see why the headers should be hidden so deeply. Installing them in 
${prefix}/include/qtN works just fine, and makes reading build logs a lot more 
legible.

@Rainer wrote:

> I only noticed this now, but it seems this change will cause problems:

Did you miss my "about MacPorts principles,  conventions (and dogmata :)) re: 
install layouts and Qt" message on this ML?

> Please do not simply drop everything related to Qt into its own prefix.

Hear hear ... I have been insisting on that for almost a year now, to no avail.

> I definitely don't want to discredit the work of René

Thanks, I for one didn't think you did. In fact, I understand that no one wants 
to do that, but there clearly isn't much intent to more than doing verbal credit 
to my work either.
(Which is why I caught wind of this thread only now: I stopped following ML 
activity that is not in reaction to a query of my own.)

> I understand that some of these parts conflict in filename

Way less that you'd think actually, largely because the original install schema 
already used qt4 and qt5 directories (in ${prefix}/share) and because the Qt5 
libraries and a number of other installed (Qt5) files have some form of Qt5 in 
their names.

Let's not forget that Qt5 was designed to co-install with Qt4 with minimal 
effort even on platforms where Qt is (almost) part of the system libraries. That 
is also why there's something called qtchooser.

@Rainer asked:
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?

It has to do with that, yes. Marko's guess notwithstanding, the real reason I 
have seen invoked is

"Qt itself installs like that on OS X"

To put it bluntly: that is true, but completely irrelevant. (Qt-for-OS X itself 
doesn't intend to be used the way it is in MacPorts.)

> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH

Guilty as charged even with my install layout. However:
- I provide symlinks suffixed with -qt4 and -qt5 for a number of commonly used 
execs
- there is port:qtchooser which also installs symlinks, to itself, and then acts 
as a wrapper that can be configured to proxy for multiple Qt installs (including 
a default install). A bit like a port select scheme, but more flexible.

R.