qt5- prefix

[René J.V. Bertin]

On Friday January 16 2015 14:52:35 Craig Treleaven wrote:

> The replaced_by keyword (and obsolete PortGroup) support what you've described:
> 
> https://guide.macports.org/#development.practices.rename-replace-port

Interesting. 

> Qt4 (or just bit rot) are going to push projects 

Bit rot, in source code? If Qt3's continued survival is any indication, Qt4 will continue to see some form of maintenance for a long time.

> to give up on Qt4.  IOW, sub-ports or variants 
> for Qt4/Qt5 should be unusual exceptions rather 
> than the norm.  Pick the right time and make the 

I frankly don't see any reason to prefer subports over independent ports; I'm pretty sure the replaced_by/obsolete functionality will work fine for subports too.

> move.  Use a -devel port if experimentation is 
> required in the interim.

In fact, -devel ports are commonly used to test a newer version of the port itself, not of some API it depends on.

Besides, there's precedence from the GTk, Python and Perl ports.

> >version-agnostic Qt PortGroup that could even 
> >include the version-specific PortGroup, though.
> 
> Could you clarify what you mean here?

Forget it, that was a little too wild an idea. I thought one could come up with some kind of common denominator PortGroup to ease the transition, but if so I need to think it over more.

> >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.
> 
> To be blunt, tough.  If a user really wants 

To be equally blunt: the user is always right.

> portfile for themselves.  The port maintainer 
> ought to pick one variant as the default.  My 

Picking a default isn't the same as imposing it, to the point of throwing in an additional Qt install.

Anyway, that's up to port maintainers to decide for their ports, and not to be imposed as dogma by MacPorts, IMHO.

> I see the Qt5 supports OS X 10.7 and later ('best 
> efforts' for 10.6, if I read it right):

Building on 10.6 is (neigh) impossible, but you can build on 10.7+ (or just 10.7?) with backward compatibility for 10.6, and then deploy to 10.6 . I've tested that by using Digia's Qt5 installed on a 10.9 VM and then copying the install dir to my 10.6.8 host. Works fine.

I'm not sure how that'd work out for the buildbots though ...


> For some ports, if the maintainer wants to keep 
> it running on old OS X versions, they might use 
> Qt4 for older OS environments and Qt5 for newer. 
> Not a variant, just do the right thing in the 
> environment.

R.