qt5- prefix

[René J.V. Bertin]

On Friday January 16 2015 08:27:18 Craig Treleaven wrote:

IIUC, your post isn't related to Qt4/5 co-installability, but to how Qt-specific versions of ports distinguish themselves.

> https://trac.macports.org/ticket/46575
> 
> If I understand correctly, Charm will create subports ala:
> 
> qt5-charm
> charm

Yes.

> Is this supposed to be a model for going forward? 

No idea.

I only picked the qt5- prefix because there's some precedence, though admittedly Qt Creator has a qt4- prefix for the Qt4 version.
Similarly, GTk ports indeed have -gtk2 or -gtk3 suffixes ... though there it might be more usual to have a GTk2 dependency be the implicit default.

> I find the "qt5-" prefix objectionable.

Frankly, I don't know and I don't have a real preference: I'm open to suggestions.
We do have the likely situation where more and more ports will transition to, or at least add support for, Qt5. As long as MacPorts doesn't provide a mechanism to signal a port name change and thus let user installations go from, say, QtCurve to qt4-QtCurve automatically, I don't see another solution of the kind I've adopted in my 2 proposals (Charm and QtCurve).

R.


> Going forward, I believe we will have the following cases:
> 1) Projects that work with Qt4 but not Qt5
> 2) Projects that work with Qt5 but not Qt4
> 3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
> 4) Projects that work with the same with Qt4 or Qt5
> 
> Assuming we have co-installable Qt4 and Qt5 via 
> MacPorts, cases 1), 2) and 4) are 
> straightforward:  'port:' style dependencies for 
> 1) and 2) and 'path:' style for 4).

AFAIC, case 4) ports will either impose a choice (port: style dependency) or leave choice to the user, as I did with Charm.
There is something to say with providing a version-agnostic Qt PortGroup that could even include the version-specific PortGroup, though.

> OTOH, there might be rare cases where users might 
> need to choose between the Qt4 version (more 
> compatible, say) and a Qt5 version (new 
> features).  Qt4/Qt5 variants would then be 
> appropriate.

If you accept that detection of the installed version is done automatically, yes. But when you do that, how do you handle the case the user has both Qt versions installed? Even if you as a port developer (knowing the port and all) have a preference, the user might not agree.

R.