[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. In D66068#1636240 , @jvesely wrote: > sorry for the delay. I fully understand the need to reduce the number of > options. Having always used SHARED_LIBS build I remember weekly shared build > breakages. This is exactly what we wa

[PATCH] D66068: cmake: Make building clang-shlib optional

jvesely added a comment. Hi, sorry for the delay. I fully understand the need to reduce the number of options. Having always used SHARED_LIBS build I remember weekly shared build breakages. That said, forcing everyone to build one huge library effectively makes debug builds unusable in any pra

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a reviewer: compnerd. beanz added a comment. In 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 insta

[PATCH] D66068: cmake: Make building clang-shlib optional

jvesely added a comment. In D66068#1627706 , @beanz wrote: > I want to dissect this a bit. > > In D66068#1627451 , @E5ten wrote: > > > I am in favour of adding a user-facing option to disable generating this > > du

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. I want to dissect this a bit. In D66068#1627451 , @E5ten wrote: > I am in favour of adding a user-facing option to disable generating this > duplicate library for users that don't need it Why do you call this duplicate? It is uni

[PATCH] D66068: cmake: Make building clang-shlib optional

E5ten added a comment. I am in favour of adding a user-facing option to disable generating this duplicate library for users that don't need it, like @jvesely says, there should be an option to disable linking a library that takes a long time to link and isn't necessary for a lot of users. Rep

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. In D66068#1626266 , @jvesely wrote: > That's your workflow. I need to run 'make install' because the modifications > are used by an external project. If there's an option to skip shlib during > 'make install' I'd be happy to use it

[PATCH] D66068: cmake: Make building clang-shlib optional

jvesely added a comment. In D66068#1625995 , @beanz wrote: > I think you and I disagree here. General developer workflows don't need to > include building `all` for every minor change. In my normal workflow I just > re-run `check-llvm` or `check-clang` o

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. I think you and I disagree here. General developer workflows don't need to include building `all` for every minor change. In my normal workflow I just re-run `check-llvm` or `check-clang` over and over again, only building the `all` target before I post a patch. With that

[PATCH] D66068: cmake: Make building clang-shlib optional

jvesely added a comment. In D66068#1625478 , @beanz wrote: > I generally am not a fan of adding more and more options. As long as you're > not linking the library it won't be generated by any of the check targets. > With the llvm dylib we've had many iss

[PATCH] D66068: cmake: Make building clang-shlib optional

beanz added a comment. I generally am not a fan of adding more and more options. As long as you're not linking the library it won't be generated by any of the check targets. With the llvm dylib we've had many issues over the years where changes to LLVM break building the dylib and many develope

[PATCH] D66068: cmake: Make building clang-shlib optional

jvesely created this revision. jvesely added a reviewer: beanz. Herald added a subscriber: mgorny. Herald added a project: clang. It takes ~5min to link, add an option to avoid that. Repository: rC Clang https://reviews.llvm.org/D66068 Files: CMakeLists.txt tools/CMakeLists.txt Index: