[MacPorts] #46238: co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent

[MacPorts]

#46238: co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  enhancement  |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.3.3
 Keywords:  haspatch     |       Port:  qt4-mac
-------------------------+--------------------------------
 Lots has been said about this on the users and dev MLs, but here it is
 finally, a draft Portfile that explores a way to make qt4-mac and qt5-mac
 co-installable, starting with qt4-mac .

 At the moment this is done as a non-optional variant, +concurrent, but the
 goal would of course be to merge that variant into the port's default
 behaviour. My intention is to tackle qt5-mac after we have reached some
 form of consensus about qt4-mac.

 The basic logic could have been very simple: instead of setting the Qt
 root directory `qt_dir` to ${prefix}, we set it to
 `${prefix}/libexec/qt4`. However, since the current version already
 installs a good number of components in Qt-version-specific places that
 approach would have been overkill. I'm thus proposing to keep those paths
 identical, to reduce the amount of breakage in dependent ports that for
 some unfathomable reason do not use the variables defined in the qt4
 PortGroup.

 Changes to the PortGroup file, qt4-1.0.tcl:

 Where we had

 {{{
     set qt_dir              ${prefix}
     set qt_docs_dir         ${qt_dir}/share/doc/${qt_name}
     set qt_plugins_dir      ${qt_dir}/share/${qt_name}/plugins
     set qt_mkspecs_dir      ${qt_dir}/share/${qt_name}/mkspecs
     set qt_imports_dir      ${qt_dir}/share/${qt_name}/imports
     set qt_includes_dir     ${qt_dir}/include
     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         ${qt_dir}/share/${qt_name}
     set qt_translations_dir ${qt_dir}/share/${qt_name}/translations
     set qt_sysconf_dir      ${qt_dir}/etc/${qt_name}
     set qt_examples_dir     ${qt_dir}/share/${qt_name}/examples
     set qt_demos_dir        ${qt_dir}/share/${qt_name}/demos
     set qt_cmake_module_dir ${qt_dir}/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
 }}}

 We get

 {{{
     set qt_dir              ${prefix}/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_demos_dir        ${prefix}/share/${qt_name}/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
 }}}

 `qt_apps_dir` remains the same, of course, as does `qt_pkg_config_dir` for
 obvious reasons (but we'll put a symlink to ${prefix/lib/pkgconfig into
 ${qt_libs_dir} because that's where installers will try to put their `.pc`
 files).

 We'll also put symlinks to `qt_qmake_cmd`, `qt_moc_cmd` etc. into
 ${prefix}/bin (qmake4.8, moc4.8 etc) ... and if port:qtchooser is
 installed there will also be ${prefix}/bin/qmake (etc) that will resolve
 the appropriate qmake (etc) version depending on the options it is invoked
 with and/or the configured defaults.

 Qt client ports will of course need to see the correct values for the
 above variables, so the variant is declared in the PortGroup file, and a
 bit of logic introduced that will check for
 ${prefix}/libexec/${qt_name}/bin/qmake to set a global state variable even
 if a port is not installed explicitly as +concurrent. This is a
 convenience feature so that we don't have to specify the variant during
 testing (and then reinstall everything without once +concurrent becomes
 the default). A note is printed about this (which should happen only once,
 but I must not understand something about the scope of global variables).


 Changes to the Portfile itself

 When I started I thought I'd do good to separate a few base definitions
 from the brunt of the Portfile, making Portfile a tiny skeleton that
 included the much larger Portfile.qt4 payload. There no longer is any
 reason to do so, but I kept this for now because it allows to modify the
 main file at will without change to the Portfile hash tag which determines
 if an automatic `port clean` has to be done.

 The main points of interest in Portfile(.qt4) are:

 - conflicts declarations are made only when concurrent isn't set
 - a symlink is made so that client ports installing a pkgconfig file do so
 in the proper location and not under the new ${qt_libs_dir}
 - links are made to expose qmake (moc, ...) in ${prefix}/bin (qmake4.8,
 moc4.8, ...)

 - A subport qt4-mac-transitional is defined. This is a pure convenience
 construct that only creates a number of symlinks in the destroot phase.
 Those symlinks make the qt4-mac+concurrent frameworks and shared libraries
 appear where they used to be, in order to remove the need to rebuild all
 Qt client ports (including all of KDE4) immediately after installing
 +concurrent. Indeed, the post-install rev-upgrade phase reports 0 broken
 ports when the install is done correctly. This subport of course
 introduces conflicts with other qt ports.
 Out-commented bits remain of the older +libsymlinks variant that did the
 same thing as the subport.

 - I introduced an optional +htmldocs variant that has to be set to install
 the html documentation. Since that amounts to almost 220Mb of lots of
 smallish files, they are in fact deleted from the source directory in the
 pre-destroot phase in order to speed up the destroot phase. Not the nicest
 approach, but since the official dogma is to do a port clean before
 installing a port with a different variants selection it shouldn't be too
 problematic.

 - I'm still working on another variant, +noexceptions, which build Qt with
 -fno-exceptions. This is supposed to be ABI compatible, and reduce memory
 overhead for a feature that is mostly unused. KDE apparently requires
 exceptions support in QtConcurrent, so I have to figure out if it's
 possible to reintroduce it there and not in the rest of QtCore.

 How to install:

 I'd advise to

 - port -v configure qt4-mac +concurrent
   check if everything looks fine
 - port -v destroot qt4-mac +concurrent
   (some time later...) check if everything looks fine in the destroot dir

 If all went well, do

 - sudo port -v -k install qt4-mac +concurrent [qt4-mac-transitional]

 qt4-mac-transitional ought not install when qt4-mac has not been installed
 with +concurrent, but can best be installed in the same command that
 installs qt4-mac+concurrent, to avoid issues during rev-upgrade.

-- 
Ticket URL: <https://trac.macports.org/ticket/46238>
MacPorts <https://www.macports.org/>
Ports system for OS X