expecting a user to use `port select` from a Portfile (re: Qt 5 support on OS X 10.6)

[René J.V. Bertin]

On Friday March 27 2015 11:33:28 Chris Jones wrote:

> How does requiring 'port select' to have been run work with the 
> buildbots, where this cannot be done ?

If I were still a 10.6 user I'd have a big preference over having to build a port myself rather than not being able to install it at all. Esp. since this is not going to be something that needs to be done often; Qt 5.3 won't evolve anymore (or very rarely).

> IMHO, if upstream have 'officially' dropped support for OSX10.6, then 

They have dropped support for building on OS X 10.6. Not for deploying to. Once built on a system with a capable compiler and the appropriate SDK, even Qt 5.4 runs perfectly fine on OS X 10.6 . That's in line with my experience that the complicated part of building on OS X 10.6 has to do with the build system. Not with the source code.
Of course that's of no help for MacPorts, where builds are always done on the target OS.

> this is not something MacPorts ports should second guess, so my 
> preference would be for the 3rd option, just drop support. This is what 
> I did with the root6 port, which had a similar issue.

The difference being that Qt is much less specialised and used by a probably much larger number of client ports. A recent Qt5 (>= 5.3) will be required for KF5 (KDE 5), for instance. If it weren't for that I would probably indeed have left 10.6 in the cold.

A fourth option I can see:

- provide a mechanism in base or a portgroup that implements a temporary alternative to port select, for building a port. Using the compiler_blacklist_versions portgroup (combined with compiler.whitelist) already introduces a build dependency on an appropriate (installed?) clang version. It shouldn't be hard to provide something (a variable or a temporary symlink) that ports can use to communicate the chosen compiler to the upstream build system.
Maybe that information can already be obtained? guide.macports.org seems to have no information about this.

R.