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

[MacPorts]

#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 at 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