From owner-freebsd-current@FreeBSD.ORG Sun Jan 6 15:45:35 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E21E195B; Sun, 6 Jan 2013 15:45:34 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 744DD6DB; Sun, 6 Jan 2013 15:45:34 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1TrsPl-0004gm-2F>; Sun, 06 Jan 2013 16:45:33 +0100 Received: from e178035121.adsl.alicedsl.de ([85.178.35.121] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1TrsPk-002Qpa-TY>; Sun, 06 Jan 2013 16:45:33 +0100 Message-ID: <50E99C1B.5080803@zedat.fu-berlin.de> Date: Sun, 06 Jan 2013 16:45:31 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces! References: <50E97457.7050809@zedat.fu-berlin.de> <50E98FB2.5040304@FreeBSD.org> In-Reply-To: <50E98FB2.5040304@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC9162AFC61F486A17E18011" X-Originating-IP: 85.178.35.121 Cc: Current FreeBSD , Brooks Davis , Ports FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 15:45:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC9162AFC61F486A17E18011 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 fee= l >> very uncomfortable haveng to have devel/llvm-devel installed while the= >> official release of LLVM is 3.2. >=20 > Please prod the port maintainer (Brooks) to update the llvm port > instead. I have CC'd him on this mail. >=20 >=20 >> The port devel/llvm is still the older >> 3.1. Is this going to be changed? >=20 > 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. >=20 > 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. >=20 >=20 >> I guess it must be synchronized with >> FreeBSD 9.X's LLVM/CLANG, isn't it (I'm on FreeBSD 10.0). >=20 > No, there is no need to be synchronized at all. That is the whole poin= t > 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 sam= e > time. In my case, I had some confusions with some LLVM related software (POCL, portable openCL library). >=20 >=20 >> 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. >=20 > 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. >=20 >=20 >> 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? >=20 > 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. >=20 > It is impossible to appease everybody with the version of llvm/clang > integrated into the base system. >=20 > Its function, for now, is simply to be able to bootstrap the system, an= d > 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.) >=20 >=20 >> 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"? >=20 > 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. >=20 > 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. >=20 >=20 >> Personally I feel much better having the complete LLVM in the base tha= n >> 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 th= e >> base system - that caused trouble for me in the past. >=20 > 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 --------------enigAC9162AFC61F486A17E18011 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ6ZwcAAoJEOgBcD7A/5N8DiAH/RYcZ7BvX1BAQe7gbWN/lExP stciJ2V4LfIjrwDkC29OHQP/DggO1bfmZ1RmWdY06N/4eiaN1KsVsukt2zbbrwua 2+UA6isJe1anD3O9P0yWZNvjNSRaGK6FolzZ0ovPI0Q3A5YUjHih6WMJ+VJfTHAG ZBx6cUdXSj5lGVUOrgTqdIJtlgvn25GZv3K/77OsZ9tDKW0HH6vXvLyb3zPAu4if 286g+jYfFoAF5rq+qcmC80kfrU/lxE55X6XEcN6W7ixEXxZa6ohjowEDaR4YD+UN MeptkAH/bCmqSbrDmQ/iUHhk/LmgxoyXeUsoX+MNLgBI04laLXgNBUKroz1vC/w= =uOYb -----END PGP SIGNATURE----- --------------enigAC9162AFC61F486A17E18011--