Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!

On 2013-01-06 13:55, O. Hartmann wrote:
> While working with an OpenCL port that is depending on LLVM 3.2, I feel
> very uncomfortable haveng to have devel/llvm-devel installed while the
> official release of LLVM is 3.2.

Please prod the port maintainer (Brooks) to update the llvm port
instead.  I have CC'd him on this mail.


> The port devel/llvm is still the older
> 3.1. Is this going to be changed?

Obviously, but this is at the discretion of the port maintainer.  If
Brooks needs more time, then you will have be a little patient.  Also
please remember that ports just came out of feature freeze.

If Brooks has no time, I can update the port too, but since I am not a
ports committer, I will still need his review and approval.


> I guess it must be synchronized with
> FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0).

No, there is no need to be synchronized at all.  That is the whole point
of a port.  With a port, you are free to update the port independently
of the base system, or even have multiple versions installed at the same
time.


> Well, this brings up again another piece of question. While FreeBSD's
> base system already has LLVM/CLANG, it is missing some important LLVM
> pieces, like llvm-config and others.

That is on purpose.  The base system only supplies the compiler, with a
minimum of dependencies, for now.  If we start supplying other LLVM
components, such as shared libraries, we will be stuck with their APIs,
and will need to maintain those for the lifetimes of the branches in
which they occur.


> Having a crippled LLVM aboard AND the need having installed a port is a
> kind of none-sense. Why should I install port devel/llvm to have a
> working LLVM backend?

Because then you would have a stock LLVM, with all the bells and
whistles that you have configured.  The version of llvm/clang in base
has a few FreeBSD-specific modifications, and some additional upstream
changes that are not in the release version.

It is impossible to appease everybody with the version of llvm/clang
integrated into the base system.

Its function, for now, is simply to be able to bootstrap the system, and
function as a system compiler.  (Read that as: it is *not* necessarily
the compiler for ports, ports can obviously make their own decisions
about using other compilers, prepackaged ones, if necessary.)


> The last time I brought up this issue, it was mentioned that the long
> compile time is one of the reasons. Can this be fixed by having an
> additional knob like "WITH_LLVM_EXTRAS"?

No, the compile time is not the reason.  The reason is having yet
another API to be maintained in base.  At the moment, clang is just one
monolithic executable, without any dependencies.  This is an advantage.

The only option added (on request from some users) is WITH_CLANG_EXTRAS,
which builds a number of tools like llc, opt, and so on.  But these
really belong in the port too.


> Personally I feel much better having the complete LLVM in the base than
> having the very same (or with bad luck, a slightly different in the
> ports) LLVM from the ports. Since it depends on the preferences of
> search paths, software used to choose the port's version prior over the
> base system - that caused trouble for me in the past.

In my opinion, the ports system should set up things so that it always
finds components under $PREFIX first, not those in the base system.  At
least, in most cases.  So if a port is dependent on devel/llvm32, it
should ensure the include and library paths are set up so it will find
the correct llvm headers and libraries.