Thrift compiler "plug-in" mode

["James E. King III" <jk...@apache.org>]

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

Re: Thrift compiler "plug-in" mode

[Jens Geyer <je...@hotmail.com>]

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 <al...@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 (jking@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.abernethy@rx-m.com
o 415-800-2922
c 415-624-6447 

Re: Thrift compiler "plug-in" mode

[Randy Abernethy <ra...@rx-m.com>]

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 <al...@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 (jking@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.abernethy@rx-m.com
o 415-800-2922
c 415-624-6447

Re: Thrift compiler "plug-in" mode

[Allen George <al...@gmail.com>]

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 (jking@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