Qt5 port group

[Craig Treleaven]

>> On May 9, 2018, at 5:00 PM, Craig Treleaven <ctreleaven at macports.org> wrote:
>> 
>>> On May 9, 2018, at 2:07 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> 
>>> 
>>> On May 9, 2018, at 07:18, Craig Treleaven wrote:
>>> 
>>>> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote:
>>>> 
>>>>> I was in the process of modifying the Qt5 Port group to allow for choosing the Qt version one wants to link an application against using variants. However, before I go further, I’d like to know if concurrent installations of different Qt5 versions are supported in MacPorts. If not, what I do is just futile.
>>>> 
>>>> Um, there are subports for each Qt5 version.  Picking one at random:
>>>> 
>>>> $ port info qt57-qtwebkit
>>>> qt57-qtwebkit @5.7.1_1 (aqua)
>>>> Variants:             debug, examples, tests, universal
>>>> 
>>>> Description:          Tools and Module(s) for Qt Tool Kit 5: Qt WebKit and Qt WebKit Widgets
>>>> Homepage:             http://qt.io
>>>> 
>>>> Extract Dependencies: xz
>>>> Build Dependencies:   python27, pkgconfig
>>>> Library Dependencies: fontconfig, icu, leveldb, webp, libxml2, libxslt, zlib, sqlite3, qt57-qtdeclarative, qt57-qtlocation, qt57-qtmultimedia, qt57-qtsensors, qt57-qtwebchannel, qt57-qtxmlpatterns, qt57-qtbase
>>>> Conflicts with:       qt3, qt3-mac, qt56-qtbase, qt58-qtbase, qt5-qtbase, qt55-qtbase, qt59-qtbase
>>>> Platforms:            macosx
>>>> License:              {LGPL-3 GPL-3 OpenSSLException}
>>>> Maintainers:          Email: mcalhoun at macports.org, GitHub: MarcusCalhoun-Lopez
>>>>                   Policy: openmaintainer
>>>> 
>>>> Notice that the port depends on several Qt5 ports which are all specified at the same level (“57”).  It conflicts with other versions of Qt.
>>>> 
>>>> Is that not sufficient?
>>> 
>>> My understanding of the fact that they conflict is that there is some latest version of Qt that is compatible with each version of macOS, and that by using the qt5 portgroup, one automatically receives that version. However, in practice, that does not appear to be the case. I see build failures of my Qt-using ports on some macOS versions because the chosen version of Qt is not compatible with that version of macOS.
>> 
>> The automatic upgrading that the portgroup does is a bit scary.  It seemed like it was no time at all that we went from 5.7.1 to 5.10.  (Even though Qt, at the time, said that they didn’t support the latest MacOS version.)  MythTV needed some fixes for Qt 5.10 for some months after MacPorts moved forward.  I still need to do some testing to see if some interface glitches are present with both 5.10 and (say) 5.5.  
>> 
>> I wish the portgroup gave some way to say “I don’t want to be on the bleeding edge but I don’t want to be stuck at Qt 5.x forever, either”.  After all, the vast majority of Linux installs are still running Qt 5.5.  Maybe this is where variants could help.  I don’t have a good solution.
>> 
> On May 10, 2018, at 8:44 PM, Marcus Calhoun-Lopez <mcalhoun at macports.org> wrote:
> 
> Your points are well taken, but I am afraid I do not have any good solutions.
> 
> It it helps, the dependencies on Qt components are of the path: variety.
> The idea was that if you wanted to stay at Qt 5.9, you only had to install qt59-qtbase.
> However, this does not work well at all with prebuilt binaries.
> I am not sure, but it might also be considered a violation of Reproducible Builds.
> 
> I am certainly open to suggestions to how to improve the situation.

Marcus, I very much appreciate all the work that you’ve done I shudder to think how many hours went into Qt5.

Would there be some way to designate that a port wishes to rely only on LTS versions?  AIUI, Qt 5.6 and 5.9 are currently the long term support versions.  Qt 5.6 is supported on macOS 10.8, 10.9, 10.10, 10.11.  (“Deployment only on 10.7”, they say.)  Qt 5.9 is supported on macOS 10.10, 10.11, 10.12.  Presumably it also works on 10.13.  Qt 5.5 is defacto supported on earlier platforms.

qt5.get_default_name would effectively become:

os.major  9 through 11, qt55
os.major 12 through 14, qt56
os.major after13, qt59

When the Qt project releases a new LTS version, I would recommend that we NOT recognize it as LTS for our purposes until at least the first major bug fix release.

I hope I haven’t missed something blindingly obvious.

Craig