[MacPorts] #47089: llvm-* all Poor user experience

[MacPorts]

#47089: llvm-* all Poor user experience
-------------------------+--------------------------------
 Reporter:  s@…          |      Owner:  macports-tickets@…
     Type:  enhancement  |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.3.3
 Keywords:               |       Port:
-------------------------+--------------------------------
 The user experience with LLVM in MacPorts is quite poor. Each version of
 LLVM (including a tip-of-tree version that is currently mislabeled as 3.7)
 is its own port. This leads to each port that depends on LLVM needing to
 have a variant for each version (each of which needs to conflict with all
 the other versions). This leads to its own problems.

 For example, if I want to install clang-3.6 from a completely fresh
 MacPorts install, what will happen is clang depends (as it should) on
 llvm-3.6 but also on cctools and ld64. So far so good except that both of
 those depend on llvm-3.5. I'm told I could give a variant of llvm-3.6 to
 clang-3.6 and that would trickle down, but I have no idea how one is
 supposed to know that's needed.

 The real problem here is that other ports like cctools don't actually care
 which version of llvm is installed since it has variants for all recent
 versions.

 As far as I can tell, there are four types of ports that could depend on
 llvm:
 1. Those that simply need the compiler backend/binaries distributed such
 as opt and presumably require a new enough version but don't care which.
 2. Those that depend on the C API and presumably require a version that's
 new enough but don't care which.
 3. Those that depend on the C++ API but are updated in lock-step with
 LLVM's ports so that in practice they don't care which version is
 installed, just so long as some version is.
 4. Those that depend on the C++ API.

 Types 1 and 2 seem simple to handle and I suspect MacPort's normal version
 mechanism is sufficient to handle it. I don't know if any ports qualify
 for type 3, but cctools looks like it might qualify (or maybe it's in type
 1, I can't tell without actually looking at the code). ld64 might be
 another case, but it also looks terrible in that it has 4 subports and 4
 variants so I'm happy to ignore that for now.

 The really tricky ones are the type 4 because the C++ API isn't stable
 (and the same is true for Clang).

 I'm not sure what the correct MacPorts method to handle this is, but it'd
 be great if ports of types 1 through 3 could simply depend on an llvm port
 and type 4 ports could depend on a specific version. If that means
 installing the C++ libraries and headers separately, that seems totally
 reasonable.

 I would hazard a guess that there are no packages X and Y such that X
 really depends on Y being linked to a particular version of llvm. There
 are certainly things like compiler front ends (e.g., Clang) and language
 bindings (e.g., llvmlite) that depends on the C++ API, but probably
 nothing a step further removed.

-- 
Ticket URL: <https://trac.macports.org/ticket/47089>
MacPorts <https://www.macports.org/>
Ports system for OS X