nilla lucene jars, as that is another package,
and I can't patch it when PyLucene is installed.
Thanks,
Jacob Floyd
My comments below.
Andi Vajda wrote:
...
>> These file depend on yet another thirdparty project, Apache Regex (?), and
>> I didn't want to have a dependency on that. Given that Python has excellent
>> regular expression support, I replaced these files with a Python-based
>> implementation.
...
>
copies of jars floating around,
possibly getting out of sync one with another.
Thanks,
Jacob Floyd
sion=${MY_PV} -Dlucene.pv=${LUCENE_PV} \
-Dpython.modname=${PYTHON_MODNAME} -Dpython.sitedir=$(python_get_sitedir) \
-Dgentoo.numfiles=2 -Dgentoo.debug=${DEBUG_OPT} -Dgentoo.root=${D} \
-Dgentoo.work=${S}
Perhaps this can be reused. I hope so. What do you all think of
replacing the Makefile lik
Well, to tell the truth the limit of my exposure to setup.py is with
pylucene and related chandler dependencies. Though I don't know
exactly when I'd be able to do something like that, any suggestions
(besides googleing it, of course) of where to learn about making the
setup.py, or even about writi
Here I am again.
After talking with some of the gentoo devs, they suggested I modify
the setup.py to include gentoo specifics and send it upstream. As it
is, they don't like to have to specify all the lflags, and in fact it
becomes troublesome, because we'd then have to duplicate what you're
doing
ue in setup.py for
> your platform.
Sweet. Thanks. The gentoo devs weren't liking the idea of exporting so
many variables in the ebuild and, at least one person called my
implementation "hackish", so I made the changes to setup.py, which hid
some of the LFLAGS that they didn't like
