I guess I find it odd that the reaction to platform-specific build
issues is to rewrite the project in another language instead of
attempting to fix the issues. There are plenty of much larger C++
projects that build on multiple platforms just fine (Ogre3d and Mozilla
come to mind).
Are there examples of Windows patches that have been submitted and
rejected? A patch that fixes something on one platform and breaks
another isn't going to be acceptable, but with appropriate preprocessor
directives, a cross-platform codebase can be created.
"Little community interest" can turn into full support if someone will
step up and work on Windows compatibility.
On 8/27/2010 11:57 AM, Jeffrey DeCew wrote:
Thrift is a project focused on bridging barriers between languages and
environments. That's why it seems strange to me that there is so little
community support for a robust Windows-friendly solution as a core part of
Thrift (especially with regard to the C++ language support). I am well
aware that speaking out in favor of Windows support is the easiest way to
get ignored on an open source software mailing list, but it seems to me that
Thrift's goal should be to achieve the broadest adoption possible. From
what I've seen the Windows support (mostly meaning willingness to commit
windows-focused patches, but also just the availability of up-to-date
patches and responsiveness of the thrift-user list) has left a lot to be
desired.
With respect to the C++ language support on Windows, I've noticed that there
are a bunch of different patches available that work with different versions
of thrift and different compiler environments, each one maintained (or not)
by a different person. These are often left as patches because they are not
general solutions that can be integrated without breaking other
environments, but they are written that way in part because their developers
see little community interest in adopting windows-helping patches into the
trunk. (I know my coworker created a QT-based TSocket and just excluded
half of the C++ runtime library to get his code to compile. He and I chose
that route over attempting to 'patch' the project because it was clear to us
that C++ patches for windows support were not being adopted.)
While a Java compiler may be far less convenient than C++ with
lexx/yacc/autotools for offices where everyone uses Linux, it seems that the
complexities of making the C++ compiler usable and accessible across all
platforms has proven to be a big problem. If adoption is important, we need
to remove as many hurdles as possible, and I believe moving to a Java
compiler is the best bet for accomplishing that.
--
Jeff DeCew
On Fri, Aug 27, 2010 at 10:50 AM, Bruce Lowekamp
<[email protected]>wrote:
+1
On Aug 27, 2010, at 10:23 AM, Anthony Molinaro wrote:
First off, I think we should stick with the current compiler for a while.
I think its quicker to package up the compiler for a few platforms, and
look at some of the patches that have been made available for building
thrift with visual studio.
If some folks want to start a branch and work on a java compiler that's
great, go for it, I'd say either a git fork of the thrift git mirror or
if you have commit access put it in a branch of svn (or even in
compiler/java,
just leave it disabled by default). When its as complete as the current
compiler a decision can be made which to use.
However, something to think about is right now there are 49 open issues
for java and 41 for C++, and 252 open issues on the jira. Before we
add to those issues with a completely new compiler, maybe we should get
the current list down to a manageable level?
And I'd like to see more tests tied into make check for more languages.
I don't think we even have basic functionality. I figured out last night
while working on a minor issue with the erlang framed transport that
the test/erl/Makefile doesn't even compile the test files and the test
files are never run. I'll be working on getting some eunit tests
tied into the make check call.
So I guess it summary, while I like the passion this conversation has
created in the community (longest thread in the past year as far as I
can tell), I think the energy has to be put into getting the current
system as solid as possible before working too much on a new system.
The project seems to be at a tipping point now, where it is being
prodded to work through its issues and hopefully graduate out of
incubator status soon. I think that a new compiler would lead to
a division of energy and a major setback in this area. After the
project has graduated and hit '1.0' then I'd think this could be
revisited.
Just my 2 cents,
-Anthony
On Fri, Aug 27, 2010 at 07:40:25AM -0700, Bryan Duxbury wrote:
An alternative would be to have unit tests that cover the basic
functionality of each of the languages' generated code and make sure
those
keep passing. (I think we should already have these tests, but I don't
expect anyone to jump up to make them.)
On Thu, Aug 26, 2010 at 6:41 PM, Todd Lipcon<[email protected]> wrote:
On Thu, Aug 26, 2010 at 6:33 PM, Greg Stein<[email protected]> wrote:
ASN.1, huh? I clicked that link. Couldn't find an overview link.
"Papers" and "presentations" and "consortium members" and all that.
Wikipedia has a more reasonable introduction. All those consortia
members should learn from that, rather than worrying about their
"international standard". :-P
That said, ASN.1 is about both description and on-wire formats. If
Thrift used ASN as the descriptive language, then people might think
it also uses the same wire format. And ASN.1 might not have things
like field tag numbers, needed by Thrift.
I don't think we're talking about a new IDL here. Just the technology
to convert those into compilable runtimes.
Yes, any incompatible change in IDL would be hugely awful.
If we plan to experiment with switching the compiler to a different
language, the acceptance test should be that it can take any thrift
file
and
generate hashwise identical code for all of the currently supported
languages.
-Todd
Cheers,
-g
On Thu, Aug 26, 2010 at 21:22, Roger Meier<[email protected]>
wrote:
talking about interface descriptions and languages to build to
compiler.
What about ASN.1 (http://www.asn1.org/) as a discription language or
pre
format?
Does somebody have a ASN.1 to Thrift compiler ?
Of course there might be some gaps, but what about that?
Am 26.08.2010 22:54, schrieb Bjorn Borud:
on the project I currently work on we have a (ANTLR-based) parser
for
the Thrift IDL language in order to generate code for a proprietary
serialization library.
it struck me that perhaps we could use this parser the implement the
Thrift compiler in Java instead. this would mean that the thrift
compiler itself could be built as a platform independent artifact --
which should make it a lot more elegant to write Maven plugins for
Thrift. it would also eliminate the need (for us) to maintain
Thrift
compiler binaries for all platforms and versions of the compiler.
currently the parser lacks some minor features, but this could
easily
be
rectified. the real job is to add the code generation for various
languages.
if anyone is interested in this, I am going to talk to some people
tomorrow to get formal approval for open sourcing it.
any thoughts?
-Bjørn
--
Todd Lipcon
Software Engineer, Cloudera
--
------------------------------------------------------------------------
Anthony Molinaro<[email protected]>
