Sweet and simple: +1 to both. a) Remove plugin feature - YES! b) but only moderately upgrade compiler code, especially don't introduce any new dependencies.
JensG -----Ursprüngliche Nachricht----- From: Randy Abernethy Sent: Wednesday, January 2, 2019 7:01 PM To: dev@thrift.apache.org Subject: Re: Thrift compiler "plug-in" mode Ditto, simple is faster, more reliable, more maintainable, more ... Let's remove the plugin feature. I would put rewriting the compiler very low on the priority list. Maybe incrementally updating the existing compiler code to C++11/17 as we go makes sense but I don't see rewriting it as a good use of the limited contributor base's time. On Wed, Jan 2, 2019 at 5:58 AM Allen George <allen.geo...@gmail.com> wrote: > > 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 -- -- Randy Abernethy Managing Partner RX-M, LLC randy.aberne...@rx-m.com o 415-800-2922 c 415-624-6447
