co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent

[RJVB (René Bertin)]

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.

[RJVB (René Bertin)]

I completely forgot to mention

• a KDE variant that applies a number of patches that improve the KDE user experience on OS X. Some of these have been presented here before.

[sicherha@…]

Cc Me!

[RJVB (René Bertin)]

Related tickets:

​https://trac.macports.org/ticket/46239 ​https://trac.macports.org/ticket/46240

[pixilla (Bradley Giesbrecht)]

Cc Me!

[mkae (Marko Käning)]

Cc Me!

[RJVB (René Bertin)]

work in progress!

[RJVB (René Bertin)]

• Files corrected to work on OS X 10.6.8
• +noexceptions should be functional now.

[springermac (Jonathan Springer)]

Cc Me!

[RJVB (René Bertin)]

concurrent mode is now the default; the older exclusive mode is available as +exclusive

[RJVB (René Bertin)]

I have not run into any issues running qt4-mac+concurrent and qt4-mac-transitional installed.

I've thus inversed the variant scheme; concurrent (coinstallable) mode is now the default, while the older exclusive mode is available as +exclusive.

Note that I have NOT yet tested to build and install qt4-mac +exclusive. It should work, but testing is going to be too costly on my hardware.

[mkae (Marko Käning)]

Hi René, I could give building it from scratch a try... Have you qt5-mac+concurrent in a working state as well? Marko

[RJVB (René Bertin)]

Just wait a little more; I haven't yet checked whether the few other ports I had to adapt (mostly remove hardcoded self-derived paths) work as they should with the new variant scheme.

And no, I haven't yet had the time to tackle qt5-mac . I was about to when I read about the missing static lib, and also discovered that the port doesn't do things the same way as Michael set up qt4-mac . As a result, I *may* try to merge the portfiles ... I'm sure you must know by now whether KF5 expects Qt5 frameworks or standard shared libraries?

[RJVB (René Bertin)]

OK, qca and qca-ossl are fine with the minor adjustments already uploaded in ​https://trac.macports.org/ticket/46239

There's also a ticket for a slightly modified kde4-1.1.tcl PortGroup definition file (​https://trac.macports.org/ticket/46240)

[pixilla (Bradley Giesbrecht)]

A diff of René's work with +concurrence rolled into Portfile.

[RJVB (René Bertin)]

Attention: the version generated through Bradley's patch-qt4-qt5-concurrence.diff​ will NOT contain the +exclusive variant that corresponds to the current default installation, NOR the qt4-mac-translational subport that preserves ABI compatibility of existing Qt4 ports with the new concurrent install.

[pixilla (Bradley Giesbrecht)]

Replying to rjvbertin@…:

Attention: the version generated through Bradley's patch-qt4-qt5-concurrence.diff​ will NOT contain the +exclusive variant that corresponds to the current default installation, NOR the qt4-mac-translational subport that preserves ABI compatibility of existing Qt4 ports with the new concurrent install.

With a variant controlling the qt{4,5}-mac conflict how is qt5-mac to know if it should or should not conflict with qt4-mac?

[RJVB (René Bertin)]

First of, it's not my intention to argue for a prolonged existence of +exclusive. But you're right, without a possibility to check what port variants are installed, qt5-mac can only do the same kind of check its and port:qt4-mac's dependents do to determine whether qt5 (or qt4) have been installed with the debug variant. That is, check for tell-tale file presence. The same applies to qt4-mac, of course.

But again, as far as I'm concerned this is a temporary situation, one that I in fact only provided for testing purposes and for potential users who prefer to stick just to the current, exclusive version, for whatever reason.

[RJVB (René Bertin)]

minor corrections

[RJVB (René Bertin)]

minor corrections

[RJVB (René Bertin)]

diff w.r.t. the current port:qt4-mac files

[mojca (Mojca Miklavec)]

Cc Me!

[RJVB (René Bertin)]

port:qt5-mac-devel has a tarball containing the full portdir and the PortGroup definition; for tester convenience I've added one here too. It contains the latest and greatest version of co-installable Qt 4.8.6 .

[RJVB (René Bertin)]

Some small changes:

• +noexceptions is now the default, and replaced by a +exceptions variant that restores the traditional build with the redundant/useless internal support for exceptions
• qtconfig.app is now built and installed to /Applications/MacPorts/Qt4

[RJVB (René Bertin)]

At Michael's (michaelld) suggestion I'm moving to a new way of distributing my ports:

​https://github.com/RJVB/mp-port-repository/tree/master/aqua/qt4-mac ​https://github.com/RJVB/mp-port-repository/blob/master/_resources/port1.0/group/qt4-1.0.tcl

This version adds the metadata required for the port select mechanism

[ctreleaven (Craig Treleaven)]

Cc Me!

[hmeine (Hans Meine)]

Cc Me!

[petrrr]

Cc Me!

[michaelld (Michael Dickens)]

This ticket's issue has been fixed/surpassed quite some time ago. Closing as fixed, even if not all of the patches were incorporated.