#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