The company I work at uses Thrift (as well as scrooge), and we don’t use the plug ins.
That said, the previous company I worked at used plugins for the _protobuf_ compiler, but that’s a completely different model, and the use of plugins there is the norm IIRC. I’d vote for simplifying the code base and removing plugins. Allen On January 2, 2019 at 08:43:40, James E. King III (jk...@apache.org) wrote: The addition of a "plug-in" compiler mode has made the build of the compiler fairly complex. There are now two kinds of compilers - one with all the code generators statically linked, and one where all the code generators are dynamically linked. I believe the original goal was to allow third parties to add their own code generator without having to maintain their own fork of thrift? As part of all the CI builds we effectively disable the plug-in part of the compiler. It had to be disabled for all distribution builds as well. Nobody distributes a plug-in compiler. As such, if anyone is using it, they are already building their own compiler, so they are maintaining their own fork. Therefore there is no real benefit. I believe the added complexity that this mode brings to the project overshadows any possible benefits of allowing for compiler plug-ins with a linked compiler like the one we have. This new compiler mode hasn't been touched in a couple years now and only one person has expressed interest in pull requests. If we want to have a more extensible compiler environment, we should consider rewriting it in another more flexible language like python. It would be easy for folks to extend it from there, however it would force a requirement on python to generate code. I'd really like us to consider eliminating the plug-in mode of the compiler to simplify the compiler build and have fewer overall build targets. Thoughts? Does anybody use the compiler plug-in mode? - Jim
