Potential bug reports

[Rush Manbert <ru...@manbert.com>]

I have been doing a lot of work lately with the library, and I have  
come across some things that I think are bugs. I went to the JIRA  
page, which says to search JIRA or ask on the list before filing a new  
report. So here I am to ask about these items.

1) The Java runtime is always copied to /usr/local/lib by make  
install. It does not pay any attention to my --prefix argument to  
configure. I also tried setting --libdir and --datarootdir but they  
made no difference.

2) The ruby install is trying to write to somewhere that requires sudo  
access, even though I have specified --prefix as a configure argument  
with a path under ~. Same problem as #1 for a different language.

3) test/cpp/src/main.cpp has the line:
       shared_ptr<TSocket> socket(new TSocket("127.0.01", port));
which should be:
       shared_ptr<TSocket> socket(new TSocket("127.0.0.1", port));

Currently, this causes a runtime error.

4) The makefiles test/cpp/Stress-test.mk and test/cpp/Thrift-test.mk  
do not pay attention to my --prefix configuration setting. They assume  
that libraries are installed in the standard locations. They also  
don't pay attention to my --with-boost directory specification for  
setting boost_home, and seem to hardcode boost-1_33_1.

I'm ready to file reports unless there are objections.

Thanks,
Rush

Re: Potential bug reports

[Rush Manbert <ru...@manbert.com>]

On Apr 11, 2009, at 4:41 PM, Todd Lipcon wrote:

> On Fri, Apr 10, 2009 at 8:40 PM, Bryan Duxbury <br...@rapleaf.com>  
> wrote:
>
>> I
>>
>>
>>
>> 1) The Java runtime is always copied to /usr/local/lib by make  
>> install. It
>>> does not pay any attention to my --prefix argument to configure. I  
>>> also
>>> tried setting --libdir and --datarootdir but they made no  
>>> difference.
>>>
>>
>> Do we really even want "make install" to do anything for Java? I'd  
>> say open
>> a ticket.
>>
>
> I believe there's a --java-prefix option to configure. Unless that's  
> part of
> a JIRA that hasn't been committed yet that I patched in locally :)


There's nothing documented in configure --help for this.

I tried using it and saw no difference, so you must have a local patch.

One other thing I noticed in this testing is that I keep getting  
javadoc creation errors because it says:

   [javadoc] javadoc: error - Destination directory not writable / 
prefix/dir/path/java/build/javadoc

which is sort of a lie because the directory it names just doesn't  
exist. So the javadoc generation uses --prefix badly and the library  
install doesn't use it at all. :-)

- Rush

Re: Potential bug reports

[Todd Lipcon <tl...@gmail.com>]

On Fri, Apr 10, 2009 at 8:40 PM, Bryan Duxbury <br...@rapleaf.com> wrote:

>  I
>
>
>
>  1) The Java runtime is always copied to /usr/local/lib by make install. It
>> does not pay any attention to my --prefix argument to configure. I also
>> tried setting --libdir and --datarootdir but they made no difference.
>>
>
> Do we really even want "make install" to do anything for Java? I'd say open
> a ticket.
>

I believe there's a --java-prefix option to configure. Unless that's part of
a JIRA that hasn't been committed yet that I patched in locally :)

-Todd

Re: Potential bug reports

[Rush Manbert <ru...@manbert.com>]

On Apr 10, 2009, at 8:40 PM, Bryan Duxbury wrote:
> <snip>

>
>> 1) The Java runtime is always copied to /usr/local/lib by make  
>> install. It does not pay any attention to my --prefix argument to  
>> configure. I also tried setting --libdir and --datarootdir but they  
>> made no difference.
>
> Do we really even want "make install" to do anything for Java? I'd  
> say open a ticket.

See next answer.

>
>
>> 2) The ruby install is trying to write to somewhere that requires  
>> sudo access, even though I have specified --prefix as a configure  
>> argument with a path under ~. Same problem as #1 for a different  
>> language.
>
> I believe that the ruby libraries try to go into site_ruby.  
> Personally, I don't think that we should even do this anymore. Do  
> you prefer to use the ruby libraries installed in this fashion for  
> some reason? I'm a big fan of the gem form of packaging and use.

I ran into this problem and the Java problem just because I didn't  
turn off anything when I configured. What I really cared about was  
installing the C++ library in my --prefix location, whci doesn't  
require sudo, but I noticed as a side issue that the Java and Ruby  
packages were being installed down in locations owned by the system. A  
couple of days later, we decided that our official Thrift build needed  
to build the Java library, but then again I couldn't put it where I  
wanted it.

In general, the way we use third party libraries is to build them once  
and check the build output into our SVN repository. Then developers  
check out the libraries, rather than checking out the sources and  
building the libraries. This insures that everyone builds using the  
same code base. If we let the developers install libraries down in the  
system locations and link against them, then it's a free-for-all when  
something goes wrong. We do this for all of our libraries, including  
Boost. For this reason, having the build and installation steps use  
the --prefix (or --exec-prefix, etc.) settings is very important to us.

What I ended up doing because of the Java problem is running  
configure, then make, then I had to cd to lib/cpp and run make install  
there in order to avoid the permission error message associated with  
the Java library, then cd back to the top and copy libthrift.jar to  
the proper location.

I can see that there might be a need for --java-prefix, --ruby-prefix,  
etc. for languages other then C++. Currently I'm just putting the  
libthrift.jar next to my C++ libraries, but that's not really the  
proper place.

>
>
>> 3) test/cpp/src/main.cpp has the line:
>>      shared_ptr<TSocket> socket(new TSocket("127.0.01", port));
>> which should be:
>>      shared_ptr<TSocket> socket(new TSocket("127.0.0.1", port));
>>
>> Currently, this causes a runtime error.
>
> Looks like we should open a ticket.

Okay.

>
>
>> 4) The makefiles test/cpp/Stress-test.mk and test/cpp/Thrift- 
>> test.mk do not pay attention to my --prefix configuration setting.  
>> They assume that libraries are installed in the standard locations.  
>> They also don't pay attention to my --with-boost directory  
>> specification for setting boost_home, and seem to hardcode  
>> boost-1_33_1.
>
> I'd say open a ticket.

Will do.
>

- Rush

Re: Potential bug reports

[Bryan Duxbury <br...@rapleaf.com>]

> I have been doing a lot of work lately with the library, and I have  
> come across some things that I think are bugs. I went to the JIRA  
> page, which says to search JIRA or ask on the list before filing a  
> new report. So here I am to ask about these items.

Thanks for being so diligent!

> 1) The Java runtime is always copied to /usr/local/lib by make  
> install. It does not pay any attention to my --prefix argument to  
> configure. I also tried setting --libdir and --datarootdir but they  
> made no difference.

Do we really even want "make install" to do anything for Java? I'd  
say open a ticket.

> 2) The ruby install is trying to write to somewhere that requires  
> sudo access, even though I have specified --prefix as a configure  
> argument with a path under ~. Same problem as #1 for a different  
> language.

I believe that the ruby libraries try to go into site_ruby.  
Personally, I don't think that we should even do this anymore. Do you  
prefer to use the ruby libraries installed in this fashion for some  
reason? I'm a big fan of the gem form of packaging and use.

> 3) test/cpp/src/main.cpp has the line:
>       shared_ptr<TSocket> socket(new TSocket("127.0.01", port));
> which should be:
>       shared_ptr<TSocket> socket(new TSocket("127.0.0.1", port));
>
> Currently, this causes a runtime error.

Looks like we should open a ticket.

> 4) The makefiles test/cpp/Stress-test.mk and test/cpp/Thrift- 
> test.mk do not pay attention to my --prefix configuration setting.  
> They assume that libraries are installed in the standard locations.  
> They also don't pay attention to my --with-boost directory  
> specification for setting boost_home, and seem to hardcode  
> boost-1_33_1.

I'd say open a ticket.


Thanks again for taking the time to report your problems.