beanz added a reviewer: compnerd. beanz added a comment. In D66068#1628617 <https://reviews.llvm.org/D66068#1628617>, @jvesely wrote:
> It duplicates functionality provided by separate/component libraries. The component libraries can't be used the way this can, and this is intended as an installed target, whereas the clang component libraries aren't. These are distinct, calling it duplicate is inaccurate and not helpful to the conversation. It may be that you don't need this library, or want it, but that is different. > Why can't this be an option the same way I can pick when building llvm? I'm going to come back to this below. > Is this a debug build? It was RelWithDebInfo, so that probably makes a big difference since it significantly reduced the amount of debug info being linked. > do you have any numbers to support that claim? Sadly we don't keep logs of 5 years worth of build breakages. Since I added the LLVM shared library build, we've had a large number of breakages because people don't build it, many of the breakages at configuration time. One of the big problems we have today with the LLVM build system is that the number of different configurations is simply massive. I certainly don't have a full understanding of all the configuration options people are using and how they are using them, and I've spent more time working on the LLVM build system than most other contributors. The variety of different configurations which conflict or overlap with each other has resulted in the build system being hard to maintain and modify. If we continue to allow each engineer to add options to the build system to make their workflow streamlined we will continue adding options until our CMake becomes completely unmaintainable. For that reason some of us have been talking about a new approach to maintaining the build system. The clang-shlib change was one of the first examples of the new approach in action. The general idea of the new approach is to not add new configurations. Instead we want to encourage people to use existing mechanisms in the build system to improve their workflow and iteration times, and I believe we have everything you need already. This does pre-suppose that engineers are willing to alter their workflows slightly to rely on different CMake options and build targets. I don't think that is an unreasonable position to come from, and frankly I think the inverse (that LLVM should adapt to each individual engineer's workflow) is unreasonable. In your workflow, rather than building `make install`, if you use the CMake `LLVM_DISTRIBUTION_COMPONENTS` option to specify which parts of LLVM & Clang you need, you can run `make install-distribution` (similarly rather than `make`, `make distribution`). This gives you tighter control than any other mechanism over what you build and install, and is the preferred way to do what you are trying to do (not build some parts of a project). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66068/new/ https://reviews.llvm.org/D66068 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
