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

Am 01/06/13 15:52, schrieb Dimitry Andric:
> 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.

In my case, I had some confusions with some LLVM related software (POCL,
portable openCL library).

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

It is hard for my little brain to accept those things ... A personal
tragedy, I guess.

I like it the way to have everything "at hand" in the base someone need,
but as a non-maintainer, I often forget about the point of maintaining.


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

Well, then the question is whether it is a big deal to build the other
portions with a special knob enabling them. The maintainer also has to
split the LLVM system anyway, apply the patches and so on. In my
imagination, then some IFDEFS/IFs are applied to get rid of what is not
needed.

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


I agree.

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

The confusing part (at least for me) starts there, where a port rquires
a compiler, like clang not providing the absolute path to the binary. i
had in the past trouble with that where port lang/clang was installed
and having used FreeBSD's aboard/base clang compiler in 10.0-CUR. It
caused some problems.

Well, what you say at the end is, that a port also should then rely on a
port compiler from the ports? That would be the logical clean slate
solution.

I might be wrong here. I'm still hoping, from the point of an user with
scietific purposes, that one day FreeBSD will make use of heterogenous
execution facilities, like OpenCL introduces: having CPU AND GPU as
possible calculation facilities. For that, LLVM seems the proper weapon
of choice. Like Apple, having this in the base system would also provide
this from the point of view of the base system. But this is possibly too
early to think about, since FreeBSD is still not any traget of GPGPU
support. Hopefully, this will change in the near future.

Maybe too much noise ...

oh