qt5 @5.6.2_0: build errors on 10.7

[mojca (Mojca Miklavec)]

This ticket may be closed as wontfix if necessary, I just wanted to summarize the build success of Qt 5.6.2 on 10.7 after resolving #52913 (before I forget).

Main job:

• ​https://build.macports.org/builders/ports-10.7_x86_64_legacy-watcher/builds/3111
• ​https://build.macports.org/builders/ports-10.7_x86_64_legacy-watcher/builds/3114

The following builds failed:

• ​qt5-qtmultimedia (with dependent ports qt5-qtdoc, qt5-qtwebkit, qt5-qtwebkit-docs)

  avfcamerautility.mm:549:92: error: property 'firstObject' not found on object of type 'NSArray *'
          AVFrameRateRange *range = captureDevice.activeFormat.videoSupportedFrameRateRanges.firstObject;
                                                                                             ^
  1 error generated.
  

• ​qt5-qtwebengine and ​qt5-qtwebengine-docs (with dependent ports qt5-qtwebview and qt5-qtwebview-docs)

  Using XCode version 4.6.3, but at least version 5.1 is required to build Qt WebEngine. 
  Using XCode version 4.6.3, but at least version 5.1 is required to build Qt WebEngine.
  QtWebEngine will not be built.
  

  Error: No files have been installed in the destroot directory!
  Error: Please make sure that this software supports 'make install DESTDIR=${destroot}' or implement an alternative destroot mechanism in the Portfile.
  Error: Files might have been installed directly into your system, check before proceeding.
  Error: org.macports.destroot for port qt5-qtwebengine returned: Staging qt5-qtwebengine into destroot failed
  

• ​qt5-qtserialbus (requires C++11 and might build with libc++)

Other builds succeeded.

[RJVB (René Bertin)]

QtSerialBus and QtWebKit both require C++11; QtWebEngine might be in the same boat but apparently no one verified that for other reasons (see below). Suppose these two ports indeed build with the cxx11 PortGroup, on libc++ enabled platforms. Wouldn't that mean that all their Qt dependencies also need to be built that way?

I think QtWebEngine is a lost cause, and that probably doesn't even depend on Qt but on Chromium (QtWebEngine is essentially Google Chrome without all the Google bits and with a thin Qt coat over it). It's in very rapid development; 5.7.0 already failed to build on OS X 10.9 which will supposedly be fixed in 5.7.1 but I kind of foresee that 5.8 may require at least 10.10 .

I'm beginning to think that QtWebEngine should be getting its own port. It certainly is large enough not to have anything of a "sub" port. Splitting it off would also be very useful in light of the foreseen introduction of port:qt5-kde but above all it will make it easier to turn it into a multi-versioned port that provides the latest supported version on each of the supported OS versions.

I think it may be a bit easier to split off the qtwebengine subport from my qt5-kde port (qtwebengine has nothing KDE-specific) so if Marcus agrees I can make up a draft which could include a 5.5.1 set-up for OS X 10.7 . The question is how many *dependents* will work with QWE 5.5x and for how long, but we'll just have to see that. There should always be the choice to keep those on a version that still uses QtWebKit.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In ad37e39e/macports-ports:

qt55: add new port

Qt 5.5 was the last version to officially support 10.7
see #51801
see #52922

[RJVB (René Bertin)]

Was that really necessary?!

Now dependents ports are going to have to determine what Qt5 port to use if they wish to support OS X 10.7 but not require a libc++ enabled OS. It might have been more useful to investigate whether C++11 support is sufficient in GCC 4.7+ to build at least QtWebKit on 10.7 .

I also hope to get an answer on my suggestion to split off QtWebEngine. It may no longer be necessary to turn that split-off into a multi-versioned port with 10.7 in mind, but it will likely require special treatment of 10.9 sooner than we'd like.

The lack of versioned dependencies in MacPorts would make it really cumbersome to manage multiple Qt5 ports for different 5.x versions in addition to qt5-kde in a way that is transparent enough that other port maintainers will actually consider using them.

[RJVB (René Bertin)]

Either way I've updated the qt5.depends_component procedure to direct ports to port:qt55 on OS X 10.7

​https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/qt5-1.0.tcl

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to RJVB:

Was that really necessary?!

I would argue that is was a good idea.
Qt 5.5 was the last version of Qt that officially supported 10.7.
Further, there was a rather significant jump between Qt 5.5 and 5.6.
As soon as qt5 is upgraded not 5.7, I also planned on creating a qt56 port as it is has ​long term support.
If it was a bad idea, others ​have made the same mistake, so at least we are in good company.

Now dependents ports are going to have to determine what Qt5 port to use if they wish to support OS X 10.7 but not require a libc++ enabled OS.

I would suggest the following solution: in qt5-1.0.tcl,

# standard Qt5 name
global qt_name

if { ![info exists qt_name] } {

    if { ${os.major} <= 7 } {
        #
        # Qt 5 does not support ppc
        # see http://doc.qt.io/qt-5/osx-requirements.html
        #
        set qt_name qt53
        #
    } elseif { ${os.major} <= 9 } {
        #
        # Mac OS X Tiger (10.4)
        # Mac OS X Leopard (10.5)
        #
        # never supported by Qt 5
        #
        set qt_name qt53
        #
    } elseif { ${os.major} == 10 } {
        #
        # Mac OS X Snow Leopard (10.6)
        #
        #     Qt 5.3: Deployment only
        # Qt 5.0-5.2: Occasionally tested
        #
        set qt_name qt53
        #
    } elseif { ${os.major} == 11 } {
        #
        # Mac OS X Lion (10.7)
        #
        # Qt 5.6: Deployment only
        # Qt 5.5: Occasionally tested
        # Qt 5.4: Supported
        #
        set qt_name qt55
        #
    } elseif { ${os.major} <= 12 } {
        #
        # OS X Mountain Lion (10.8)
        # OS X Mavericks (10.9)
        # OS X Yosemite (10.10)
        # OS X El Capitan (10.11)
        #
        # Qt 5.7: Supported
        # Qt 5.6: Supported
        #
        set qt_name qt5
        #
    } elseif { ${os.major} <= 16 } {
        #
        # macOS Sierra (10.12)
        # as of Qt version 5.7, there is no official support
        #
        set qt_name qt5
        #
    } else {
        #
        # macOS ??? (???)
        #
        set qt_name qt5
        #
    }
}

In Portfiles, replace dependency port:qt5-qtbase with path:lib/pkgconfig/Qt5Core.pc:${qt_name}-qtbase.
This would be fairly minimal change that would also allow us to finally commit qt5-kde since it is a drop-in replacement.
I have a script that makes the changes to Portfiles.

It might have been more useful to investigate whether C++11 support is sufficient in GCC 4.7+ to build at least QtWebKit on 10.7.

You seem to have made progress in building Qt with MacPorts compilers, but to me, Qt seems very intent on using OS compilers.
With such a large piece of software as Qt, I would prefer to stay as close to the supported configuration as possible.

I also hope to get an answer on my suggestion to split off QtWebEngine. It may no longer be necessary to turn that split-off into a multi-versioned port with 10.7 in mind, but it will likely require special treatment of 10.9 sooner than we'd like.

Please correct me if I am wrong, but isn't QtWebEngine already a subport in both qt5 and qt5-kde?
Are you suggesting that we create a new Portfile?
If so, I would prefer to keep it a subport.
If fits in well enough with the machinery that exists in the qt5 Portfile.

The lack of versioned dependencies in MacPorts would make it really cumbersome to manage multiple Qt5 ports for different 5.x versions in addition to qt5-kde in a way that is transparent enough that other port maintainers will actually consider using them.

Is my proposed solution above sufficiently easy for Portfile maintainers to use?
It seems to fit in with standard MacPort practices.

[RJVB (René Bertin)]

Replying to MarcusCalhoun-Lopez:

As soon as qt5 is upgraded not 5.7, I also planned on creating a qt56 port as it is has ​long term support.

This has already been discussed on Trac or the ML; the consensus was that maintaining support for 5.6 only makes sense if newer Qt versions drop support for OS X versions that we'd like to continue to support. But if 10.8 support is dropped only in Qt 5.8, why would we maintain a Qt 5.6 port if we could just as well maintain 5.7 as our own LTS version?

I would personally prefer to maintain platform-specific maximum versions in a single Portfile as much as possible, but that is less cumbersome for me since qt5-kde uses only 3 distfiles at the moment.

If it was a bad idea, others ​have made the same mistake, so at least we are in good company.

I'm not sure if HB is good company in this aspect :)

I would suggest the following solution: in qt5-1.0.tcl,

In Portfiles, replace dependency port:qt5-qtbase with path:lib/pkgconfig/Qt5Core.pc:${qt_name}-qtbase.
This would be fairly minimal change that would also allow us to finally commit qt5-kde since it is a drop-in replacement.
I have a script that makes the changes to Portfiles.

That's comparable to but considerably more complicated and less readable than my solution. We may end up with something similar, but we're not there yet.

With my proposal, Portfiles can just use expressions like

qt5.depends_components qtsvg qtdeclarative qttools qtwebkit

to declare dependencies on anything that is not added automatically by the actual PortGroup. If port:qt5-kde (or port:qt5-kde-devel, in my or Marko's case) is used this translates to

depends_lib-append path:libexec/qt5/Library/Frameworks/QtCore.framework/QtCore:qt5-kde \
    path:libexec/qt5/Library/Frameworks/QtWebKit.framework/QtWebKit:qt5-kde-qtwebkit

because only QtWebKit has its own real subport (there's no point in installing stubs ports if it can be avoided).

otherwise it translates to

depends_lib-append path:lib/pkgconfig/Qt5Core.pc:qt5-qtbase \
    port:qt5-qtsvg \
    port:qt5-qtdeclarative \
    port:qt5-qttools \
    port:qt5-qtwebkit

(or idem with qt55 instead of qt5 on 10.7)

Port:qt5-kde indeed installs the .pc files in the same location as port:qt5, but it would not be wise as a general rule to allow ports to mix and match Qt components from port:qt5-kde and port:qt5. Path-style dependencies work great, but they only allow the user to install an alternative port explicitly. If the requested dependency is not already provided, it is still the port specified after the colon that will be installed, and that shouldn't be port:qt5-foo instead of port:qt5-kde-foo or vice versa.

It might have been more useful to investigate whether C++11 support is sufficient in GCC 4.7+ to build at least QtWebKit on 10.7.

You seem to have made progress in building Qt with MacPorts compilers, but to me, Qt seems very intent on using OS compilers.
With such a large piece of software as Qt, I would prefer to stay as close to the supported configuration as possible.

Actually, I think they only do that because they consider that it's the only compiler that people have available, and at some point there must have been a reason not to rely on the clang proxies installed in /usr/bin. Do you have explicit statements of the contrary?

Please correct me if I am wrong, but isn't QtWebEngine already a subport in both qt5 and qt5-kde?
Are you suggesting that we create a new Portfile?

Yes, it is. It does however not contain anything specific to KDE, but it will very likely drop support for older OS X versions quicker than the rest of Qt, meaning an additional OS/Qt version aspect to manage.

Is my proposed solution above sufficiently easy for Portfile maintainers to use?

Not really IMHO. To summarise:

• maintainers will have to specify the path:-style dependencies explicitly
• the installed "flavour" would have to be made available in qt_name to avoid all (future) possibility for untested mix-and-match

It seems to fit in with standard MacPort practices.

Yes, and evidently the wrapper I add on top of it just hides the more cumbersome aspects of those practices.

I have implemented a similar wrapper to specify dependencies on KF5 frameworks (there are 60+ of those...) and it makes it both much easier to specify a list of dependencies and to read the resulting Portfiles. All you have to deal with are names of components (frameworks), no need to bother with prefixes and names of the files that indicate whether they're installed or not.

In any case, we must come to an agreement on solving the PortGroup hurdle via a header PortGroup that includes the actual PortGroup (and includes some shared stuff). If that solution is retained, I'd propose myself as the principal maintainer of that header PortGroup (which doesn't and won't change anything in the way port:qt5 works). It seems only fair that I'd bear the brunt of the extra work, and I have been able to be more reactive in addressing issues in the recent past.

[RJVB (René Bertin)]

Something I just realised:

There's a potential issue with ports providing different versions of a same set of libraries like Qt and that can all satisfy dependencies because path:-style declarations are used. Qt 5.6 is backwards ABI compatible with Qt 5.5, but an application built against Qt 5.6 is likely to fail when Qt 5.5 is installed.

This is fine if port:qt55 is installed *only* on OS X 10.7, but if users can also decide for themselves that they need to install port:qt55 instead of port:qt5 *) they will have problems with binary packages if nothing is done to prevent that.

*) they may develop software that has to be deployed on 10.7 for instance.

I have a similar possible issue with port:qt5-kde providing a somewhat richer API and ABI than port:qt5, which I avoid by using an automatic variant to distinguish ports built against port:qt5-kde. This ensures that the build bots will not serve the wrong build. The principle is simple: if the PortGroup (qt5-kde-1.0 in my case) detects an alternative port (qt5-kde), it declares and sets a default variant. If the build bots have ports with that default variant users can enjoy prebuilt binaries, otherwise they will build the ports from source.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 77ec1368/macports-ports:

qmake5-1.0.tcl: avoid mixing libc++ and libstdc++

see #52922

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In ec39a5a3/macports-ports:

qt5-qtmultimedia: build on Mac OS X 10.7

see #52922

[mojca (Mojca Miklavec)]

What's the proper way for ports to add dependencies on Qt5 after you introduced the qt55 ports?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to mojca:

What's the proper way for ports to add dependencies on Qt5 after you introduced the qt55 ports?

#51619 is currently being tested.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

qt56 now builds on 10.7 for all modules except qtwebengine, qtwebview, qtwebview-docs, and qt5-qtwebengine-docs.
Since there is no realistic way to add support for these modules on 10.7, I will mark this as fixed.