#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