[MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
MacPorts
noreply at macports.org
Mon Oct 5 01:53:56 PDT 2015
#44193: qt: allow side by side installation of qt4-mac and qt5-mac
-------------------------------+------------------------
Reporter: mojca@… | Owner: mcalhoun@…
Type: enhancement | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: qt4-mac, qt5-mac |
-------------------------------+------------------------
Comment (by rjvbertin@…):
I'll try to make this short, but the code extracts cancel most of the
effort :)
> it takes forever to build Qt4 on some systems.
Interesting, the other day I did the build with nice +15 and only 3 out of
my 2*2 cores (2 real, 2 HyperThreads), while watching 2 episodes in
QuickTime - and I think the build was done well before I finished the 2nd,
i.e. in less than 1.5hours. That's a lot of time to wait turning thumbs,
but not exactly "forever" ;)
Since it seems more than 1 person here will be rebuilding, maybe we can
collect some statistics, for future reference?
Also, I'd be more than happy to maintain a qt4-mac-devel port (i.e. with
commit access), for exactly the suggested purpose (port development, test-
bed, whatever you want to call it). Getting a GSoC student to handle my
changes rather than letting me do it myself ... am I being a jerk if I say
that feels like an insult?
qt4-mac vs qt4 "tout court": I'd say there is no real need to change this.
Everyone is used to the qt4-mac name for the port, and even if there's no
more need to use a -mac vs a -x11 suffix I don't think there's a real
advantage to dropping the suffix either. Besides, there's nothing that
stops someone from reviving qt4-x11; it should be possible to get it to
build still using the latest Qt version that still built for X11 (last
time I checked Fink has such a "port" too). Above all, it seems a waste of
time to force a rebuild of all dependents just for a change of name ...
The only thing I champion is NOT to use qt4-mac for the prefix path, and
that is also because Qt4 locations have been using `qt4` directories.
Now, for a minimal change to make Qt4 concurrent, I would propose the
following settings in the Qt4 PortGroup (I'm leaving the 2 comments I have
in mine):
{{{
# standard Qt4 name
global qt_name
set qt_name qt4
set qt_dir ${prefix}/libexec/${qt_name}
set qt_dir_rel libexec/${qt_name}
set qt_docs_dir ${prefix}/share/doc/${qt_name}
set qt_plugins_dir ${prefix}/share/${qt_name}/plugins
set qt_mkspecs_dir ${prefix}/share/${qt_name}/mkspecs
set qt_imports_dir ${prefix}/share/${qt_name}/imports
set qt_includes_dir ${prefix}/include/${qt_name}
set qt_libs_dir ${qt_dir}/lib
set qt_frameworks_dir ${qt_dir}/Library/Frameworks
set qt_bins_dir ${qt_dir}/bin
set qt_data_dir ${prefix}/share/${qt_name}
set qt_translations_dir ${prefix}/share/${qt_name}/translations
set qt_sysconf_dir ${prefix}/etc/${qt_name}
#set qt_examples_dir ${prefix}/share/${qt_name}/examples
set qt_examples_dir ${applications_dir}/Qt4/examples
set qt_demos_dir ${applications_dir}/Qt4/demos
# no need to change the cmake_module_dir, though I'd have preferred to
# put it into ${prefix}/lib/cmake as qt5-mac also does, and which is the
place Linux uses
set qt_cmake_module_dir ${prefix}/share/cmake/Modules
set qt_qmake_cmd ${qt_dir}/bin/qmake
set qt_moc_cmd ${qt_dir}/bin/moc
set qt_uic_cmd ${qt_dir}/bin/uic
set qt_lrelease_cmd ${qt_dir}/bin/lrelease
}}}
* and for configure.args in the Portfile :
{{{
# 20151003 : -prefix ${prefix} instead of -prefix ${qt_dir} (as with Qt5)
would be
# great, but will lead to frameworks in ${prefix}/Library/Frameworks
instead
# of in ${qt_dir}/Library/Frameworks ...
configure.args-append \
-v \
-confirm-license \
-opensource \
-prefix ${qt_dir} \
-bindir ${qt_bins_dir} \
-libdir ${qt_libs_dir} \
-docdir ${qt_docs_dir} \
-headerdir ${qt_includes_dir} \
-plugindir ${qt_plugins_dir} \
-importdir ${qt_imports_dir} \
-datadir ${qt_data_dir} \
-translationdir ${qt_translations_dir} \
-sysconfdir ${qt_sysconf_dir} \
-examplesdir ${qt_examples_dir} \
-demosdir ${qt_demos_dir} \
-openssl-linked \
-dbus-linked \
-fast \
-optimized-qmake \
-no-pch \
-framework \
-no-phonon \
-no-phonon-backend \
-fontconfig -system-freetype
}}}
and to re-absorb the sqlite3 plugin subport into the main port so that
`port:qt4-mac` itself doesn't require that subport in order to be able to
run the applications it installs:
{{{
# the sqlite3 plugin ("sqlite") has been re-absorbed into the main port
however
configure.args-append -system-sqlite
depends_lib-append port:sqlite3
foreach driver {mysql odbc psql sqlite2} {
configure.args-append -no-sql-${driver}
}
}}}
Doing this means removing the `port:qt4-mac-sqlite3-plugin` dependency in
dependent ports, or change them to
`path:${qt_plugins_dir}/sqldrivers/libqsqlite.dylib:qt4-mac-
sqlite3-plugin` (as has already been done in the KDE4 PortGroup).
* I'd suggest looking at the changes to build without internal use of
exceptions, which is actually the preferred way to build Qt (and the
default in Qt5). I've added a variant to re-enable use of exceptions, but
I don't think there's any point to that. Contrary to Qt's own -no-
exceptions build, mine doesn't disable exceptions in the few components
that do require them (just like Qt5 does).
{{{
configure.args-append -no-exceptions
# (26) don't build with exceptions, which gives a completely ABI-
compatible build
patchfiles-append disable-exceptions.patch
post-destroot {
if {![variant_isset exceptions ]} {
# building with -no-exceptions will add a section to
QtCore/qconfig.h that has to be removed
# given that we did NOT build QtCore WITHOUT exceptions...
exec patch -d ${destroot}${qt_frameworks_dir} -Np0 -i ${filespath
}/qconfig-remove-EXCEPTIONS.diff
}
}
}}}
IIRC, current `port:qt4-mac` sets and then "configure.args-delete"'s
`-optimized qmake`, for a reason that's unclear to me. I disabled that and
haven't had any issues, and qmake is considerably faster because of it.
I also use
{{{
pre-configure {
configure.env-append MAKEFLAGS=-j${build.jobs}
}
}}}
to build qmake in parallel, which can make a big difference. NB: that's
the "official" way to do it.
A few useful things from my post-destroot :
{{{
post-destroot {
# Move .apps into the applications_dir, and link each .apps'
# executable back into ${qt_bins_dir}
set dr_qt_apps_dir ${destroot}${qt_apps_dir}
set dr_qt_bins_dir ${destroot}${qt_bins_dir}
xinstall -m 755 -d ${dr_qt_apps_dir}
foreach app [glob ${dr_qt_bins_dir}/*.app] {
# remove the leading stuff
set app [lindex [split ${app} /] end]
# move the .app
move ${dr_qt_bins_dir}/${app} ${dr_qt_apps_dir}
# link it back
ln -s ${qt_apps_dir}/${app} ${dr_qt_bins_dir}
# provide a proxy to the app's executable; symlinks won't
# be accepted by qtchooser if the user has that port installed.
set texe [strsed ${app} {g@\.app@@}]
set appProxy ${dr_qt_bins_dir}/[string tolower ${texe}]
copy ${filespath}/appProxy.sh ${appProxy}
reinplace
"s|@BUNDLEEXEC@|${qt_apps_dir}/${app}/Contents/MacOS/${texe}|g"
${appProxy}
ln -s ${qt_qmake_cmd} ${destroot}/${prefix}/bin/qmake-
qt${qt_major}
ln -s ${qt_moc_cmd} ${destroot}/${prefix}/bin/moc-qt${qt_major}
ln -s ${qt_uic_cmd} ${destroot}/${prefix}/bin/uic-qt${qt_major}
ln -s ${qt_lrelease_cmd} ${destroot}/${prefix}/bin/lrelease-
qt${qt_major}
# expose KDE4 styles to Qt4:
ln -s ${prefix}/lib/kde4/plugins/styles
${destroot}${qt_plugins_dir}/
}
}
}}}
That's about all I can think of now. The only thing that I'd really hope
to get in at this point are the install locations and to a somewhat lesser
extent, preservation of the port name(s) and the re-absorbtion of the
sqlite3 plugin. If I'm not overlooking anything else won't introduce
incompatibilities with the changes I've been "evolving" and that I'm
running locally. I'd just as well like to avoid having to rebuild
everything *again* just because "you guys" haven't been keeping up with me
:P
--
Ticket URL: <https://trac.macports.org/ticket/44193#comment:67>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list