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

 > > each port that depends on LLVM needing to have a variant for each
 version
 >
 > This isn't an "llvm" thing.  The same is true for python, perl, ruby,
 and a ton of other ports.  That's the whole point of variants.

 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)
 }}}

 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.

 > > except that both of those depend on llvm-3.5
 >
 > Well if you want llvm-3.6, use that variant.
 >
 > > 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.

 {{{
 steve$ port info clang-3.6
 clang-3.6 @3.6-r229298 (lang)
 Variants:             [+]analyzer, [+]assertions, universal

 Description:          Clang is an LLVM native C/C++/Objective-C compiler,
 which aims to deliver amazingly fast compiles (e.g. about 3x faster than
 GCC when compiling
                       Objective-C code in a debug configuration),
 extremely useful error and warning messages and to provide a platform for
 building great source
                       level tools. The included Clang Static Analyzer is a
 tool that automatically finds bugs in your code, and is a great example of
 the sort of tool
                       that can be built using the Clang frontend as a
 library to parse C/C++ code.
 Homepage:             http://clang.llvm.org/

 Fetch Dependencies:   subversion
 Extract Dependencies: subversion
 Build Dependencies:   cctools
 Library Dependencies: libxml2, llvm-3.6, python27, libedit, libffi,
 ncurses, zlib, libcxx
 Runtime Dependencies: clang_select, ld64, perl5
 Platforms:            darwin
 License:              NCSA
 Maintainers:          jeremyhu at macports.org, larryv at macports.org
 }}}

 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.

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

 > > Those that simply need the compiler
 >
 > They pull it in via configure.compiler or blacklisting other compilers.

 Sounds good.

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

 >
 > > Those that depend on the C++ API
 >
 > Assuming you mean a newer version of C++, then yes, but that's not
 really any different than #1

 I do not. I mean the unstable C++ API I mean.

 I don't think this bug report is invalid unless user experience isn't one
 of MP's goals.

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