compnerd wrote: > Well, we're currently approaching this from the angle of "expose everything > and then the user can do whatever they want", but perhaps the discussion we > should be having is "what use cases do we explicitly want to support?" and > then we write plugins to demonstrate that we do support those use cases, > exposing what's necessary as part of that process. This does mean that use > cases we hadn't anticipated may be frustrating for users, but we can more > easily expand the surface area of what we expose than we can claw it back > once we've exposed it publicly.
Ah, so ... this is interesting. There are two separate "competing" goals here. The GSoC project was about enabling clang plugins. My goal has always been different (which I've clearly articulated on discourse). My motivation is supporting a DLL build of LLVM, clang, LLDB. The idea is to reduce the size of the toolchain distribution by using dynamic linking of LLVM and sharing the code rather than statically linking all libraries. This also then opens up a second opportunity for only doing PGO/LTO/BOLT on a single DLL that can be shared across all the tools. The hope is to actually allow page sharing and reduce memory pressure, reduce load times on Windows (because the libraries are paged in and mapped), and reduce the toolchain size. An ideal scenario in my mind is that we are able to create the following DLLs: 1. LLVMSupport.dll 2. LLVM.dll 3. clang.dll 4. LLDB.dll (which potentially already exists as liblldb.dll) clang and the binary tools would depend on LLVM.dll. The clang tools could depend on LLVM and clang DLLs. This would of course allow us to minimise the exported interface to what clang and the binary tools need. https://github.com/llvm/llvm-project/pull/109702 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
