I think I tested the python, but not the smalltalk namespace.
However, there's a bigger problem that the smalltalk generator is calling back
into program_ to lookup namespaces using "smalltalk.<foo>" while it's
registered as a generator for "st" so the root check only allows "st.foo"
namespaces. I really hate this, but if there are people using this, maybe the
best fix would be to hard-code the converstion to "st":
(note: I ran the smalltalk generator this time to make sure the "category" line
was there, but would in no way claim to have tested the smalltalk.)
Bruce
Index: compiler/cpp/src/generate/t_st_generator.cc
===================================================================
--- compiler/cpp/src/generate/t_st_generator.cc (revision 990302)
+++ compiler/cpp/src/generate/t_st_generator.cc (working copy)
@@ -121,6 +121,7 @@
void st_accessors(std::ofstream &out, std::string cls, std::string name,
std::string type);
std::string class_name();
+ static bool is_valid_namespace(const std::string& sub_namespace);
std::string client_class_name();
std::string prefix(std::string name);
std::string declare_field(t_field* tfield);
@@ -181,7 +182,7 @@
return capitalize(program_name_);
}
-static bool is_valid_namespace(const std::string& sub_namespace) {
+bool t_st_generator::is_valid_namespace(const std::string& sub_namespace) {
return sub_namespace == "prefix" || sub_namespace == "category";
}
Index: compiler/cpp/src/parse/t_program.h
===================================================================
--- compiler/cpp/src/parse/t_program.h (revision 990302)
+++ compiler/cpp/src/parse/t_program.h (working copy)
@@ -164,6 +164,10 @@
std::string base_language = language.substr(0, sub_index);
std::string sub_namespace;
+ if(base_language == "smalltalk") {
+ base_language = "st";
+ }
+
t_generator_registry::gen_map_t my_copy =
t_generator_registry::get_generator_map();
t_generator_registry::gen_map_t::iterator it;
On Aug 27, 2010, at 3:23 PM, David Reiss wrote:
> I think that's a bug in trunk. The smalltalk generator is definitely in
> there an generates namespace-less smalltalk code just fine.
>
> --David
>
> On 08/27/2010 03:02 PM, Michael Greene wrote:
>> The .exe dreiss built looks good for at least Python and C# on Windows 7.
>> The smalltalk generator is not built, which I don't care about, but the
>> first test I ran was on tutorial.thrift which fails on the smalltalk
>> namespace even if you're not trying to generate code for it.
>>
>> Michael
>>
>> On Fri, Aug 27, 2010 at 3:55 PM, David Reiss <[email protected]> wrote:
>>
>>> Pending approval from other committers, I'm going to commit a number of
>>> changes to Thrift's build scripts and source code (the latter are
>>> minor). A preview of the changes is at
>>>
>>>
>>> http://gitweb.thrift-rpc.org/?p=thrift.git;a=log;h=refs/heads/pri/dreiss/build-changes;hb=HEAD
>>>
>>> You can click "commitdiff" next to each commit to see the full diff.
>>> I'll upload patches to JIRA shortly. These changes span the following
>>> issues: 500, 503, 505, 506, 507, 850, 865, 874.
>>>
>>> The new features include:
>>>
>>> - "make check"-enabled C++ tests moved from /test to /lib/cpp/test
>>> - configure accepts --disable-cpp to skip building the C++ runtime.
>>> - The compiler no longer depends on Boost.
>>> - The compiler no longer requires lex or yacc, if building from a
>>> release (or instant release) tarball. (This is why thrifty.h,
>>> thrifty.cc, and thriftl.cc are included in the tarballs. I just had
>>> to make a small change to remove the dependency on libfl.)
>>> - A script is included to cross-compile a Windows binary of the Thrift
>>> compiler from a stock Ubuntu 10.04 machine (with the gcc-ming32
>>> package).
>>>
>>> I was able to build the compiler from a release-style tarball on a stock
>>> CentOS 5.2 machine (with g++ installed via yum) by running
>>>
>>> ./configure && make -C compiler/cpp
>>>
>>> Note that this machine does *not* have autoconf, automake, libtool, lex,
>>> flex, yacc, bison, or boost installed.
>>>
>>> I am not able to test on a Mac, but I would appreciate if the people who
>>> have had problems building on Mac OS X would download this tarball, run
>>> the same command, and report any problems they encounter. If I don't
>>> hear back, I will assume that there are no problems whatsoever building
>>> on Mac OS X: http://people.apache.org/~dreiss/thrift-e0db3ee.tar.gz
>>>
>>> Because procedure to cross-compile for Windows is so ridiculously easy,
>>> I will be producing Windows binaries of the compiler for all of our
>>> future releases. You can nab a build of the latest trunk at
>>> http://people.apache.org/~dreiss/thrift-e0db3ee.exe
>>>
>>> --David
>>>
>>