#47089: llvm-* all Poor user experience --------------------------+-------------------------------- Reporter: s@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: invalid | Keywords: Port: | --------------------------+-------------------------------- Comment (by jeremyhu@…): Replying to [comment:2 s@…]:
Replying to [comment:1 jeremyhu@…]:
including a tip-of-tree version that is currently mislabeled as 3.7
What makes you think that 3.7 is "mislabled"?
It's mislabeled because there's no such thing as 3.7. The port is just some version from svn that hasn't undergone the standard release process which includes significant testing.
And it is called "3.7svn" by upstream. The versioning is appropriate. The same thing is done in a multitude of other ports, including gcc5.
I believe you that there are other similar ports, Python, at least, isn't in the same boat. There really are important differences between the various versions of Python (although this too is a hassle). And even still, this is different. Each port of a Python package ends up with ports (subports, maybe?) for each version of Python:
{{{ steve$ port search numpy|grep ^py..-numpy py26-numpy @1.9.2 (python, math) py27-numpy @1.9.2 (python, math) py33-numpy @1.9.2 (python, math) py34-numpy @1.9.2 (python, math) }}}
For python modules, yes. For clients, no.
There's no chance that if I install py27-foo, which happens to depend on numpy, that MacPorts will try to install py33-numpy to satisfy the dependency. I can't speak to the other examples you cite.
That is not really a good analogy.
I have no idea how one is supposed to know that's needed
port info will tell you about variants.
Actually no, it won't.
Actually, it will: {{{ $ port info cctools cctools @862_1 (devel) Variants: llvm33, llvm34, [+]llvm35, llvm36, llvm37, (+)universal Description: A set of essential tools to support development on Mac OS X and Darwin. Conceptually similar similar to binutils on other platforms. Homepage: http://opensource.apple.com/source/cctools/ Build Dependencies: libunwind-headers Library Dependencies: llvm-3.5 Platforms: darwin License: APSL-2 GPL-2+ Maintainers: jeremyhu@macports.org, openmaintainer }}}
Which is precisely my point. I can't imagine you expect users to do port rdeps on each package they want to install, and then run port info on each looking for variants they should set.
That is not a problem with the llvm ports. The same thing applies to pretty much every port with variants.
Also, you could just install both. clang-3.5 is one of the default fallback compilers, so chances are you'll need it for something unless you want to modify your compiler choices as well.
That in and of itself should tell you that there's a problem. I suspect that as a compiler, most packages don't need version 3.5. I suspect that most just need a compiler and some need a compiler that is new enough. I ''could'' install multiple versions, but I shouldn't need to and that's part of what makes the user experience so poor.
Again, that's not a problem with the llvm port. Your issue there is with base. And as far as ports needing a new enough compiler, llvm-3.6 *itself* needs a new enough compiler, which is why clang-3.5 is installed to build it if you have something older than Xcode 4.6.
Those that depend on the C API
Uh, ... no ... the host provides the C API
You misunderstand. libLLVM (and libclang) expose a stable C API (in .../include/llvm-c) and an unstable C++ API (in .../include/llvm). It's this stable C API I mean.
Oh, well then yes, clients of that should either depend on a specific version or should have variants to let users choose which version of llvm they want to use.
I don't think this bug report is invalid unless user experience isn't one of MP's goals.
Well, there is nothing actionable. This isn't the proper forum. You have concerns with MacPorts in general, and you are using the llvm port as an example. There is nothing specific to the llvm ports that are a problem here. If you want to see improvements, I suggest you start a discussion on the mailing list as that is a more appropriate forum for discussing things at that level. -- Ticket URL: <https://trac.macports.org/ticket/47089#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X