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

[René J.V. Bertin]

On Saturday December 09 2017 11:35:07 Ryan Schmidt wrote:

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

AFAIU it's necessary at least on older systems that don't come with libc++. It doesn't seem to be required on 10.9 (and up, thus), for now. Also, with clang being the size it is there's a strong incentive to keep only a single version installed (or active, at least), and with compilers that typically means a newer rather than an older version. This is all the more true on older Mac OS versions that by definition already have an older system compiler.

>> But maybe `depends_build` will also attempt to upgrade the dependencies it declares before building the dependent?
>
>Of course it will.

I don't think that's so evident.

>Why would we change that? It works correctly.
...
>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.

Evidently, but those are direct dependencies. Those arguments should be much weaker for build dependencies, let alone for runtime dependencies.

Yes, "it" works correctly, but see below for a few examples where "it" could work a bit more conveniently (not to say better).

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

FWIW, the above should be a relatively easy way to avoid circular dependencies. No need even to detect them, a simple variation on the current scheme should suffice, I think. Currently upgrades aren't attempted when a port has already been upgraded (even in the current run). The scheme above only changes the threshold for this behaviour, from "upgrade applied" to "upgrade triggered".

Evidently I'm not really intimately familiar with the base internals nor have I actually tried this so it's perfectly possible that I'm overlooking something that'd be evident if I were/had.

Most of the time there's no need to support circular dependencies, but there are a few exceptions. I recall seeing a remark in one of the ports I tinker with (can't remember which one right now) and I have a port myself where I'd love to be able to introduce a *runtime* dependency on a subport which has a hard dependency on the main port. The subport provides a plugin without which the main port loses most of its usefulness. Qt's SQL plugins are another good example (for Qt4 at least), here the sqlite3 plugin is actually required.

R.