llvm-* all Poor user experience

[stevecheckoway (Stephen Checkoway)]

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.

[jeremyhu (Jeremy Huddleston Sequoia)]

including a tip-of-tree version that is currently mislabeled as 3.7

What makes you think that 3.7 is "mislabled"?

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.

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

Those that simply need the compiler

They pull it in via configure.compiler or blacklisting other compilers.

Those that depend on the C API

Uh, ... no ... the host provides the C API

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

[stevecheckoway (Stephen Checkoway)]

Replying to 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@macports.org, larryv@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 don't think this bug report is invalid unless user experience isn't one of MP's goals.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to s@…:

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

[neverpanic (Clemens Lang)]

FWIW, the requested variants discussion on the list could ease some of the pain here. See #46956.

[stevecheckoway (Stephen Checkoway)]

Replying to jeremyhu@…:

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 don't believe that's true ​http://llvm.org/releases/ (3.7 only appears in the skeleton release notes), but this isn't a very important point and if it's common practice in MacPorts, then so be it.

That is not really a good analogy.

It's not completely analogous, but it demonstrates that by having different ports (or maybe subports), there's never a version mismatch whereas by using variants, there can be.

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

That's cctools, not clang. Unless the user is expected to examine all variants of dependencies recursively by hand, port info doesn't tell you what you need to know.

Again, that's not a problem with the llvm port. Your issue there is with base.

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.

Fair enough. I appreciate your time. Thank you.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to s@…:

Replying to jeremyhu@…:

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 don't believe that's true

Well the maintainers of llvm do, and that's who I'll trust:

commit f11d9b193361e73c28aea5acb40962f636843e04
Author: Hans Wennborg <hans@hanshq.net>
Date:   Wed Jan 14 17:38:03 2015 +0000

    Trunk is now 3.7.0svn
    
    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226004 91177308-0d34-0410-b5e6-96231b3b80d8

​http://llvm.org/releases/ (3.7 only appears in the skeleton release notes),

Yes, because those are beta as well.

but this isn't a very important point and if it's common practice in MacPorts, then so be it.

That is not really a good analogy.

It's not completely analogous, but it demonstrates that by having different ports (or maybe subports), there's never a version mismatch whereas by using variants, there can be.

No, it's not analogous because the type of ports are different in those cases. In the py26-numpy case, something is providing a module for use by clients of different versions of perl, python, ruby, etc. In those cases, the *numpy* code is exactly the same, it's just built and installed for use by a different version of python.

In this case, the different llvm ports *are* different versions of llvm. This is analogous to why we have multiple python ports or multiple gcc ports, etc.

Clients of llvm can have variants to let users choose which version of llvm they want to use.

Clients of python (or the py-numpy module) similarly can have variants to let users choose which version of python (and thus py-numpy) they wish to use.

Actually, it will:

That's cctools, not clang.

Yes. cctools is the one that has the variant. 'port info' will tell you about a port's variants.