[pylucene-dev] About compiling with gcc 4.2

[David Pratt]

Hi Greg, Andi has been pretty much been single-handedly helping everyone 
on this list with very good and timely advice. I think you are a bit off 
base with your comments. Admittedly, the compile time is long - but 
PyLucene itself is real software ingenuity - and it also takes what it 
takes to compile. I am sure Andi would not turn down binaries from folks 
who have taken time to compile on various platforms.

As far as documentation, pick up a copy of 'Lucene in action' which is 
an excellent resource. All the workable code from the book is included 
in the PyLucene sources and there is plenty to read in the samples. If 
you look at the archives of this list you will find plenty in the way of 
discussion on the quirks of various builds and platforms over time - 
most of which Andi has captured in the Makefile as these were reported.

This is a young project and the evolution of compilers, which are 
complex, certainly adds to the mix. I would not take this as disregard 
for your platform or project, but more as evolution that takes time. 
Your need to be patient with gcc and gcj as they evolve - or contribute 
to solutions to fix them. If you are asking for assistance, come with 
some appreciation of the effort that has gone into this software and the 
folks behind it.

I am sure as time goes on there will eventually ports and packages on 
various platforms once there is some real stability. As an example, 
binaries of jdk are now being maintained as part of FreeBSD's ports 
collection. I would see some opportunity to distribute safe binaries 
further down the road. That said, folks will need to step up to maintain 
a port or package for their distribution system when that time arrives.

Right now, we ought be thankful that builds of PyLucene on gcc-4.2 
(beta) are beginning to succeed on certain platforms (since that last 
time this happened was gcc-3.4.6 for most part).

Regards,
David


Greg Kuperberg wrote:
> On Thu, Nov 23, 2006 at 10:44:12AM -0800, Andi Vajda wrote:
>> In any case, it's not that hard to build yourself, it takes a few hours 
>> depending on the speed of your system.
> 
> I have to say that a few hours is not a very good standard for
> installing software such as PyLucene.  I am used installing software
> in a few minutes.  When I can't use yum, apt-get, or rpm, I am used to
> the three-line installation procedure, "configure; make; make install".
> Indeed, a configuration script is an important intermediate step that
> makes it easier for other people to make RPM packages and Debian packages.
> I have been using Unix for 20 years, admittedly more as a user than
> as a developer, and I have never been very happy with hand-configuring
> Makefiles.
> 
> Moreover, in this case I depend on PyLucene for a project that I may
> want to "sell" to other people.  Part of the sell is going to be that
> it isn't too hard for them to install.
> 
> PyLucene is an important project.  It is a bridge between Python,
> which is monumentally important, and Lucene, which is also important.
> When PyLucene works, it works really well, because Lucene is more
> complete and more scalable than many alternatives.  PyLucene is also
> faster than Lucene itself.  That said, I think that the difficult of
> installing PyLucene, and maybe also the haphazard documentation, are
> the main shortcomings of the project right now.  I think that you could
> multiply your user base by 10 if you concentrated on documentation and
> installation for a while.
> 
> If OSAF has other priorities for PyLucene or for your time otherwise,
> then you have every right to point that out.  On the other hand, Chandler
> itself is supposed to be for user-friendly collaboration.  It's strange
> for them not to care more about cross-Unix installation.
>