Diwaker 
What is the issue you are trying to address that you are seeing in your day to 
day development with this ticket? Initially you could remove given languages 
not in use from the compiler and this was removed in favor of always having 
available every language that is possibly to be generated. This should have no 
impact on any test cases or libraries you wish to not include. Configure also 
offers the ability to compile without any of the client libs with the 
--without-<LIB> option. This should allow you to compile and test the client 
libs that you are looking at using and you will not have to worry about 
dependencies for libraries you are not going to use. What problem are you 
running into that you are trying to address?

- Jake




On Dec 12, 2011, at 6:39 PM, Diwaker Gupta (Created) (JIRA) wrote:

> Decouple Thrift IDL from generators
> -----------------------------------
> 
>                 Key: THRIFT-1463
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1463
>             Project: Thrift
>          Issue Type: Wish
>          Components: Compiler (General)
>            Reporter: Diwaker Gupta
>            Assignee: Jake Farrell
> 
> 
> While Thrift's broad language support is fantastic, it does impose many 
> constraints on day to day development.
> 
> * The current design of the compiler make it hard to improve and test the 
> generator/library for a particular language. The codebase is monolithic and 
> hard to navigate.
> * Each language has it's own idiosyncrasies. For instance, the Java library 
> required ant to build, the Ruby library has other dependencies. Running unit 
> tests is slightly different for each language library. Currently, all of this 
> is duck-taped together (barely) using 'make', which has its own flaws.
> * Adding support for a new language is fairly easy, but rather than making 
> the code more modular, it adds to the current complexity of the codebase. For 
> example, setting up Jenkins jobs to test/verify builds for a new language 
> take a while to come up to parity with other languages.
> 
> I think Google's Protocol Buffer approach is instructive here. They're trying 
> to strip down the core compiler and decouple the IDL from language specific 
> stubs. For a rich environment like Thrift, I think this decoupling is crucial 
> to allow for a more maintainable and testable code base going forward. To 
> refresh:
> 
> * the core compiler takes in a Thrift grammar file and generates an 
> intermediate representation: think of an in-memory AST
> * each supported language will be implemented via plugins, that can be loaded 
> at runtime by the compiler
> * the plugins take this AST and transform it into source code
> * each plugin can be in its own repository (consuming the compiler via a git 
> submodule, for instance). Plugins can freely choose their own build system, 
> unit test frameworks etc
> * a meta repository can contain the compiler, and the 'blessed' (officially 
> supported) languages. This meta repository can include integration tests that 
> will test language interoperability
> 
> I realize, of course, that this will be a big change. But we have to start 
> somewhere.
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators: 
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
> 

Reply via email to