Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 6 Jan 2013, at 20:38, Erik Cederstrand wrote: > You can't seriously blame LLVM for making progress. If ports rely on a > specific version of LLVM, it would be far better to create devel/llvm31, > devel/llvm32 etc. Well, I can (and, even with my LLVM committer hat on, do) blame LLVM for not having a sensible deprecation strategy. Breaking the ABI is unavoidable in a C++ project (unless you invent an entire metalanguage on top of C++, as Qt does) but breaking the API is a huge pain, when it would be no more effort in most cases to stick on a deprecation attribute telling people what they should be using instead. Having llvm31, llvm32, and so on ports is likely to be unavoidable, as lots of external projects end up depending on older versions of LLVM. It would be worth splitting out clang from these. A few refactoring-type tools depend on old versions of clang, but most commonly people will be using latest clang with latest LLVM, plus something else with old LLVM. David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 2013-01-06 21:38, Erik Cederstrand wrote: Den 06/01/2013 kl. 18.25 skrev "O. Hartmann" : In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. Indeed, this is a serious point and the developer of LLVM has to be blamed for that. You can't seriously blame LLVM for making progress. If ports rely on a specific version of LLVM, it would be far better to create devel/llvm31, devel/llvm32 etc. Yes, I think that is probably the most effective approach. It should also be possible to install multiple versions simultaneously. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Den 06/01/2013 kl. 18.25 skrev "O. Hartmann" : >> In contrast, LLVM changes the ABI (and API!) significantly between point >> releases. We therefore don't want to encourage anything outside of the base >> system to link against these libraries, because doing so would prevent us >> from importing a new LLVM release every six months - we'd either need to >> ship 4 copies of LLVM by an x.3 release, or stick with the one that we >> shipped in x.0. > > Indeed, this is a serious point and the developer of LLVM has to be > blamed for that. You can't seriously blame LLVM for making progress. If ports rely on a specific version of LLVM, it would be far better to create devel/llvm31, devel/llvm32 etc. Erik ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 6 Jan 2013 14:57, "Dimitry Andric" wrote: > > On 2013-01-06 15:16, Erik Cederstrand wrote: > ... > >> I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. > > > Well, it would be easy enough to build llvm-config, but what should its > output be? We do not install llvm/clang headers or libraries into the > system, so llvm-config would not give any meaningful -I or -L flags. :) > > > >> llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. > > > Again, build time is not the problem. The libraries are already built, > but in static form; making them dynamic would not be that difficult, but > installing them would add another maintenance and compatibility burden. > > > >> The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. > > > Yes, this seems to be the proper approach. But, as far as I understand, > the ports system cannot yet do one work tree build, and package that up > in different packages, such as -libs, -devel, and so on. No, but it can be done if the parts are compiled separately, à la postgresql-* ports. Is this definitely impossible? It's crudely but effectively done with pgsql by only running make in certain directories... Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Am 01/06/13 17:49, schrieb David Chisnall: > On 6 Jan 2013, at 12:55, O. Hartmann wrote: > >> 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? > > The issue is the same as the issue for anything in the FreeBSD base system, > which is: what level of compatibility do we want to provide? > > In general, we aim to provide a backwards-compatible ABI across an entire > major release. This means that anything that runs on 9.0 should work on 9.1 > and so on. It should also work on 10.x with the relevant compat packages > installed. > > In contrast, LLVM changes the ABI (and API!) significantly between point > releases. We therefore don't want to encourage anything outside of the base > system to link against these libraries, because doing so would prevent us > from importing a new LLVM release every six months - we'd either need to ship > 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in > x.0. Indeed, this is a serious point and the developer of LLVM has to be blamed for that. > > There is no problem with other base-system tools linking against the base > system LLVM libraries, but in this case llvm-config does not need to be > installed (and neither do the LLVM headers), because such tools will be built > as part of the base system itself. llvm-config is simply as an example. It shows up the first when the build of POCL fails, so I have chossen it to be checked for as the relevant dependency - it was a hunch for the port Makefile I intend to provide. Since I was more focused on having POCL running for my OpenCL moveon on FreeBSD, I wasn't very careful about choosing what to check against. I will change this before I will send the port to be reviewed and revised. > > David > ___ signature.asc Description: OpenPGP digital signature
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 6 Jan 2013, at 12:55, O. Hartmann wrote: > 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? The issue is the same as the issue for anything in the FreeBSD base system, which is: what level of compatibility do we want to provide? In general, we aim to provide a backwards-compatible ABI across an entire major release. This means that anything that runs on 9.0 should work on 9.1 and so on. It should also work on 10.x with the relevant compat packages installed. In contrast, LLVM changes the ABI (and API!) significantly between point releases. We therefore don't want to encourage anything outside of the base system to link against these libraries, because doing so would prevent us from importing a new LLVM release every six months - we'd either need to ship 4 copies of LLVM by an x.3 release, or stick with the one that we shipped in x.0. There is no problem with other base-system tools linking against the base system LLVM libraries, but in this case llvm-config does not need to be installed (and neither do the LLVM headers), because such tools will be built as part of the base system itself. David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
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. > I also filed a PR ( http://www.freebsd.org/cgi/query-pr.cgi?pr=175059). It seems, that the port devel/llvm-devel also misses some pieces of the most recent LLVM 3.2, as it is needed to compile POCL properly, but I leave this with the experts to change. I try to follow a logical path: devel/llvm represents the recent release, while devel/llvm-devel should be the development branch, 3.3 by now. I do not know whether we need LLVM 3.1 any more, since apart from the POCL device driver backend via LLVM for OpenCL target I know about nothing in the FreeBSD realm by now using LLVM. I might be wrong ... So, I see forward to hear from the decissions made ;-) Oliver signature.asc Description: OpenPGP digital signature
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Am 01/06/13 15:57, schrieb Dimitry Andric: > On 2013-01-06 15:16, Erik Cederstrand wrote: > ... >> I think the real problem is that LLVM and the related tools are build >> in one go, so you can't easily build llvm-config and others for the >> base version of LLVM. > > Well, it would be easy enough to build llvm-config, but what should its > output be? We do not install llvm/clang headers or libraries into the > system, so llvm-config would not give any meaningful -I or -L flags. :) The problem at this point is that I personally do not exactly understand the real dependency of the software i try to build as a port (POCL, now RC2 at sourceforge). The build system requires llvm-config and I guess the LLVM backend for the LLVM IR for the target (at the moment, only the CPU). > > >> llvm-config needs shared libraries that are not installed in base >> because they supposedly require a prohibitive amount of build time. > > Again, build time is not the problem. The libraries are already built, > but in static form; making them dynamic would not be that difficult, but > installing them would add another maintenance and compatibility burden. > > >> The LLVM port could be split up instead. There could be a >> devel/llvm-libs port that installed the shared libs for the base LLVM, >> and then a devel/llvm-config, devel/scan-build or devel/mclinker port >> that depends on the former port. > > Yes, this seems to be the proper approach. But, as far as I understand, > the ports system cannot yet do one work tree build, and package that up > in different packages, such as -libs, -devel, and so on. Why splitting up? My problem is NOT the compile time, the burden on an oldish Intel Core2Duo E8400 is not that much and I'm, personally, have installed the port devel/llvm-devel. So I guess now I reeled in everything I need and want to have (without exactly knowing what to need). My question was to have the whole thing in the base. But you made clear this is more an disadvantage than advantage. > > >> This might require that a larger part of the LLVM source tree is >> imported into src/contrib, though. > > I am not sure what you mean by this. Why would the ports require > something in the base system, other than a compiler? signature.asc Description: OpenPGP digital signature
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 o
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
On 2013-01-06 15:16, Erik Cederstrand wrote: ... I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. Well, it would be easy enough to build llvm-config, but what should its output be? We do not install llvm/clang headers or libraries into the system, so llvm-config would not give any meaningful -I or -L flags. :) llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. Again, build time is not the problem. The libraries are already built, but in static form; making them dynamic would not be that difficult, but installing them would add another maintenance and compatibility burden. The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. Yes, this seems to be the proper approach. But, as far as I understand, the ports system cannot yet do one work tree build, and package that up in different packages, such as -libs, -devel, and so on. This might require that a larger part of the LLVM source tree is imported into src/contrib, though. I am not sure what you mean by this. Why would the ports require something in the base system, other than a compiler? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
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. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!
Den 06/01/2013 kl. 13.55 skrev O. Hartmann : > While FreeBSD's > base system already has LLVM/CLANG, it is missing some important LLVM > pieces, like llvm-config and others. llvm-config is a build dependency that spits out some lib paths that you can just hard-code for FreeBSD. So what in "others" does your port need? I think the real problem is that LLVM and the related tools are build in one go, so you can't easily build llvm-config and others for the base version of LLVM. llvm-config needs shared libraries that are not installed in base because they supposedly require a prohibitive amount of build time. The LLVM port could be split up instead. There could be a devel/llvm-libs port that installed the shared libs for the base LLVM, and then a devel/llvm-config, devel/scan-build or devel/mclinker port that depends on the former port. This might require that a larger part of the LLVM source tree is imported into src/contrib, though. Erik ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
