
Hi, Luke Tucker wrote:
I came across a slight issue with the part of lxml's setup.py that adds a link flag for exslt when libxslt is installed in a directory with a name containing the string 'xslt'.
--------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm ---------------------------------------------------------------------
in this case, the snippet above produces a list like
--------------------------------------------------------------------- -L/home/ltucker/devel/deliverance.buildout/parts/libexslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxslt/lib -L/home/ltucker/devel/deliverance.buildout/parts/libxml2/lib -lxslt -lxml2 -lz -lm ---------------------------------------------------------------------
Sure, it replaces the first occurrence, which usually is "-lxslt", so it's expected to add "-lexslt" at that position. Not very robust, as your example shows... Can we rely on every supported compiler to accept "-lxslt" as library parameter? Well, I guess most people use gcc anyway...
I believe this problem would apply to the lxml buildout as well, but it doesn't call the parts/libxslt/bin/xslt-config.
Don't know, never tried.
Do questions about the lxml buildout go to this list?
Definitely the best place for it.
As a related side note, it might be nice to have the setup.py complain if 'xslt-config' can't be found. If it isn't around, it appears to silently create an etree.so with no dependencies on libxml2/xslt/exslt.
As I said, not the most robust code ever. I don't have much time currently, so if you could come up with a patch... Stefan