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

[Ryan Schmidt]

On Dec 9, 2017, at 11:26, René J.V. Bertin wrote:

> 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.

Long, as in: The ticket has 58 comments on it. The ticket was open for two weeks. I spent hours trying different things and verifying it built on different OS versions.


>> 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?

No.

> As far as I can see (and know) the blacklisting does nothing against that, but will only prevent the compiler from being chosen automatically.

That's correct. Command line compiler selections override blacklisting. I'm not convinced that's the best behavior, but it is the current behavior.


> 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.

Why is it necessary to attempt to build cmake with recent clang?


> 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?

Of course it will.

> If so, couldn't that be changed in base?

Why would we change that? It works correctly.


> 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)?

We want dependencies upgraded first. Often, that's the whole point of an upgrade.

e.g. ncurses is updated to a new version with a new library version. We revbump ports depending on ncurses. ncurses *has* to be built before the other ports, otherwise rebuilding the other ports defeats the purpose.


> 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

As far as I know, MacPorts makes no attempt to detect that a circular dependency exists, it merely assumes that it doesn't exist, and its behavior is undefined if it does. So we should not attempt to create circular dependencies.


> 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 =]