does cmake really need to blacklist macports-clang >= 3.8?

[René J.V. Bertin]

On Saturday December 09 2017 10:01:41 Ryan Schmidt wrote:

> As far as I know, the port works as is, and it took a long time to get it that way.

What do you call long? I can easily imagine that the issues (on pre-10.9 systems that don't use libc++ as the standard C++ runtime) commented on in the Portfile took a long time to figure out. The protection against circular dependencies seems more like an implementation of a principle.

> Why do you want to change it and risk breaking it again?

Have you actually tried to install cmake from source using `configure.compiler=macports-clang-x.y` where x.y corresponds to a blacklisted compiler that you haven't yet installed? As far as I can see (and know) the blacklisting does nothing against that, but will only prevent the compiler from being chosen automatically.

The main concern behind this thread was that building cmake would become impossible using a recent clang, esp. using clang 5+ with its new features that don't compile with older versions.
But come to think of it, if the commandline configure.compiler override is not a glitch in my local install it also means that this concern is moot.




I still think there should be no need to blacklist clang versions if you're upgrading cmake though, i.e. if cmake already exists:

{{{
if {![file exists ${prefix}/bin/cmake]} {
    foreach cv {3.8 3.9 4.0 5.0} {
        ui_debug "blacklisting macports-clang-${cv} because it might need us for installation"
        compiler.blacklist-append macports-clang-${cv}
    }
}
}}}

But maybe `depends_build` will also attempt to upgrade the dependencies it declares before building the dependent? If so, couldn't that be changed in base?

Or on a more general note, is there anything that would break if base kept track of ports already queued for upgrading and simply accept to use the current version the next time it encounters a dependency on one of those ports (that's more or less what it does with deactivated ports, no)?

Concretely:
upgrade cmake from source
	-> best available compiler? clang-mp-5.0, is there an update for it (to be built from source?)
		-> no -> build cmake
		-> yes -> upgrade clang-5.0
			-> build depends on cmake, which we're upgrading (or installing)
				-> is a cmake version available? -> use it
				-> no cmake available? -> fail with a circular dependency error


BTW, the assumption here is that the simple fact of using a compiler provided via a port will trigger any upgrades available for that compiler (or its dependents?). That is of course also something that could be deferred: don't upgrade something you're about to use.

R.

Apologies if this was all nothing but a bout of rambling, it's a snowy, cold saturday afternoon =]