[jira] [Comment Edited] (THRIFT-3013) make thrift compiler accept a list of input files

["Roger Meier (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14488444#comment-14488444 ] 

Roger Meier edited comment on THRIFT-3013 at 4/9/15 10:57 PM:
--------------------------------------------------------------

My view on this:
* thrift-compiler -> a single executable on all platforms
* generated C++ code -> run everywhere with up-to-date compilers and no dependencies(only things like boost thread if enabled by option)
* test suite -> additional dependencies such as boost program options are okay as long as they help simplify things for *make cross* such as standard parameter sets for testing across languages. 
* tutorial -> take care on dependencies, these things have to rock out of place directly

Of course in-tree source for the capability of program option parsing is an option but required sync with upstream and this is a pain as we know from autoconf and co...
There is getopt_long from BSD eco system vs. boost or [POCO|https://github.com/pocoproject/poco] program options from C++ area. Why do we miss one of the most common topics such as program option parsing within C++ standard set?
-roger

PS: If we are able to deliver a thrift executable on all platforms and provide them via popular package managers(deb, nuget, npm, ?), the dependencies during build time will become irelevant.
;-r


was (Author: roger.meier):
My view on this:
* thrift-compiler -> a single executable on all platforms
* generated C++ code -> run everywhere with up-to-date compilers and no dependencies(only things like boost thread if enabled by option)
* test suite -> additional dependencies such as boost program options are okay as long as they help simplify things for *make cross* such as standard parameter sets for testing across languages. 
* tutorial -> take care on dependencies, this things have to rock out of place directly

Of course in-tree source for the capability of program option parsing is an option but required sync with upstream and this is a pain as we know from autoconf and co...
There is getopt_long from BSD eco system vs. boost or [POCO|https://github.com/pocoproject/poco] program options from C++ area. Why do we miss one of the most common topics such as program option parsing within C++ standard set?
-roger

PS: If we are able to deliver a thrift executable on all platforms and provide them via popular package managers(deb, nuget, npm, ?), the dependencies during build time will become irelevant.
;-r

> make thrift compiler accept a list of input files
> -------------------------------------------------
>
>                 Key: THRIFT-3013
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3013
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Compiler (General)
>    Affects Versions: 0.9.2
>            Reporter: Xiaoshuang LU
>            Assignee: Roger Meier
>         Attachments: THRIFT-3013.patch, THRIFT-3013.v2.patch
>
>
> At present, customer could specify one input file to the thrift compiler.  There are maybe two approaches to support multiple input files.
> Approach 1: Improve the option parser in compiler/cpp/src/main.cc.  Maybe we can borrow code from GUN's getopt_long.
> Approach 2: Offer uses a maven plugin which can help them to iterate through a list of input files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)