On Thu, 16 Oct 2014 07:24:53 -0500, Rex Dieter wrote:
There are several strategies:
* The <bin>-qt5 convention is already used by most distributions, so many
applications/tools have adapted to it already. If you're aware of any that
haven't yet, I'd be happy to help produce upstreamable patches to implement
such support.
* qt5-qtbase-devel provides rpm macros (in /usr/lib/rpm/macros.d/macros.qt5)
that are useful during package creation, including:
%_qt5_qmake
%_qt5_bindir
As you noted, one way to ensure Qt5 gets used is to prepend %_qt5_bindir to
$PATH. This is essentially what kf5's %_cmake_kf5 (and similarly
%_cmake_kde4) macros do.
That (even if shortened) would be a great addition to %description or
a "README.Fedora". I mean, those are customisations and could/should be
mentioned somewhere, so using the RPM packages does not require listing
files and trying to solve the puzzle.
* As far as 'moc', that's not *usually* a tool an
end-user typically runs,
so we've never seen a need to provide easy access (via pkg-config, or rpm
macro). If you have a justifiable use-case, we can certainly add it.
Did you mean UIC and not MOC? I'm aware of Qt based programs (my own
ones included) that pregenerate source files from UI forms prior to
wrapping up the source tarball release - but do other programs nowadays
really ship files pregenerated using MOC?
Btw, the program I've had to build is Audacious from git, the ongoing
port to Qt with --enable-qt. It expects "moc" in path, and the plugins
package expects "uic" in path.