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