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?Received on Sun Jan 06 2013 - 13:57:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC