Why do some ports insist on devel/llvmxx?

ShelLuser

ShelLuser

Hi gang,

Almost finished with manually setting up a new FreeBSD system and right now it's busy sorting out some ports I want to have. And as usual all of a sudden devel/llvm40 pops up somewhere in the middle.

On my older 10.3 server I guess I could understand considering that the compiler in the base is Clang 3.4, but on my freshly set up Amnesiac (love the default name) which is FreeBSD 11.1 (but completely unconfigured right now) the Clang version is 4.0.0, and now I'm looking at 4.0.1 getting pulled in. And that made me question the relevance.

So what gives? What could bring someone to build depend on the external compiler?

I guess it is possible that a port maintainer made very specific changes to the build process and added flags which directly targeted a specific Clang version. I can't help doubt this theory, but it's possible I suppose.

My more favorite theory though is that a package maintainer figured "I need a compiler", noticed the existence of Clang in the ports collection and a build dependency was just one line of code away.

To be honest I'm having mixed feelings here. After all: the time it takes to build that thing is quite heavy on older systems, and considering the fact that there's already a version available in the base system makes the whole thing look extremely redundant to me. But... is that also really the case?

What do you think?
 
Sometimes, a newer LLVM or CLANG works out older bugs, has new features, is more efficiently developed, etc. Perhaps they want to develop on the newest LLVM port, because it's progressive.

You can set it to the newer compiler in make.conf. For Programming languages, sometimes I just install the package from the repository: this often works, except when there's a newer patch or build (often of the same version).

Some stress to not mix ports and packages like so, but if you were to do it, be sure both are set to the same of either Latest or Quarterly.
 
getopt said:
at least time and energy can be saved using the port version and skipping the bootstrap build of the toolchain there and deploy without base Clang. :)
Click to expand...
In src.conf(5), Clang is listed twice, both say they install the compiler. One as a bootstrap, and one during the normal phase of the build. Do you know if it installs twice if both are enabled? Or is one only a bootstrap?
Anyway, as you were saying, a user can do without base's Clang and Clang bootstrap and use Clang from ports? I think I tried this successfully, but another time I over did it, by removing other things, then had a system where I couldn't build. Just wanted to make sure, before I tried this again.
sidetone said:
For Programming languages, sometimes I just install the package from the repository: this often works, except when there's a newer patch or build (often of the same version).
Click to expand...
(and compiler backends) referring to LLVM or Clang.
 
sidetone said:
In src.conf(5), Clang is listed twice, both say they install the compiler. One as a bootstrap, and one during the normal phase of the build. Do you know if it installs twice if both are enabled? Or is one only a bootstrap?
Click to expand...
Depends which options you're looking at, and your FreeBSD version.

On 11.1 (the one you linked) there's a strict separation, and I believe the description says it all... WITHOUT_CLANG vs. WITHOUT_CLANG_BOOTSTRAP where the latter explicitly mentions the requirement for an existing compiler if you want to boot it.

So it's only a bootstrap, considering the name.

It becomes a little more obscure in older versions though.
 
Code: 
WITHOUT_CLANG
        Set to not build the Clang C/C++ compiler during the regular phase of the build.
...
    WITH_CLANG
        Set to build the Clang C/C++ compiler during the normal phase of the build.
...
    WITHOUT_CLANG_BOOTSTRAP
        Set to not build the Clang C/C++ compiler during the bootstrap phase of the build.  You must enable either gcc or clang boot-strap to be able to build the system, unless an alternative compiler is provided via XCC.
...
    WITH_CLANG_BOOTSTRAP
        Set to build the Clang C/C++ compiler during the bootstrap phase of the build.
Perhaps it's a mistake by who wrote the documentation to say both are the compiler. Either way, the bootstrap is needed to use the compiler from ports, if XCC is not used.
getopt said:
skipping the bootstrap build of the toolchain there and deploy without base Clang. :)
Click to expand...
This look like it implied the bootstrap wasn't needed. It was ambiguous. I think I see what was meant.
 
sidetone said:
Perhaps it's a mistake by who wrote the documentation to say both are the compiler.
Click to expand...
I doubt it, and I also fail to understand the confusion. I mean: one is build during the normal phase whereas the other is build during the bootstrap phase. And it is a known fact that if build the base system it'll start by bootstrapping/building its compiler first.

So yeah, I don't understand what's so confusing about this.
 
graphics/mesa-dri insists on LLVM40. This is in /usr/ports/graphics/mesa-dri/Makefile.common. It likely requires a newer version than the default, and llvm50 is untested for it.
Code: 
COMPILER_TYPE=clang
COMPILER_VERSION=50
in /etc/make.conf mentioned from /usr/ports/Mk/Uses/compiler.mk doesn't override it.
This sets CC, CXX, and CPP for versions mentioned in compiler.mk, where llvm is not mentioned yet. CC, CXX, and CPP don't override it anyway.
 
Last edited:
Well, I still have very mixed feelings about the whole thing because "newer" isn't always better. And so far.. I actually tried setting up a 10.3 system, installed a 'mockery' LLVM port (so not the real thing) and then started compiling stuff. So far so good, even some ports which had LLVM as their build dependency easily build using Clang from the base system.

So far my theory is still that some port maintainers got their priorities seriously mixed up and also don't stop to think about the impact of their choices.
 
sidetone said:
If it works, all llvm build options should be on the table, via make.conf and not forced. It's good to know base llvm works with it too. Compiling graphics/mesa-dri, a dependency for x11-servers/xorg-server, worked with LLVM50.
Click to expand...

In the changelog for graphics/mesa-dri, there is this statement:

Mesa supports both llvm40 and llvm50. The former remains the default as it's what the OpenCL ports currently require and it's available on more platforms.​

So there you go. If you go to clang’s 4.0 release notes, there are a number of OpenCL bug fixes, which is likely why the OpenCL ports require 40.
 
You must log in or register to reply here.
Back
Top