Whoops, I replied to this, but I sent only to Martijn by accident. Earlier message: I think it might also be good in general to call the xslt-config that is built by the buildout (the one in parts/libxslt/bin) whenever possible. I was having related issues on systems with no pre-installed xslt-config/headers with the deliverance buildout (which is based on the lxml buildout, thanks btw) There could theoretically be link flag differences as well if the system-wide/built-out versions had different dependencies. I wound up pushing parts/libxslt/bin onto the front of PATH with a recipe before calling lxmls setup, but there may be cleaner ways. There is a separate issue I mentioned in "lxml setup.py exslt link flag" related to doing this but I haven't gotten back to this yet to write a patch. If it helps, the deliverance buildout is at: http://codespeak.net/svn/z3/deliverance/buildout/trunk/ - Luke On Mon, 2006-11-20 at 16:40 -0600, Ian Bicking wrote:

Martijn Faassen wrote:

...

Hi there,

I reported previously that I created a buildout for lxml, but today I found out that is of limited utility: while it correctly links lxml against any libxml2 and libxslt library, it does still require the libxml and libxstl2 *headers* to be where xslt-config locates them, i.e. probably /usr/include

I tried to hack up the setup.py so it would look elsewhere (it is supposed to respond to things like --include-dirs), but setup.py has grown to be rather complicated. This is a common problem with configuring from Python code - it grows all kinds of things which look useful but also make it very hard to expect some kind of uniform behavior across different systems configuring themselves this way.

I hope that setup.py can still be adjusted so that buildout can be made to work. I *think* it's only not responding to --include-dirs that does it in.

Luke Tucker has been trying to resolve these same issues in the Deliverance buildout. I don't know the status -- hopefully he'll chime in -- but the work is in http://codespeak.net/svn/z3/deliverance/buildout/trunk

On Mon, November 20, 2006 6:07 pm, Ian Bicking wrote:

Why doesn't xml-config go in the top-level bin/ directory? It seems like that path should also be on the front of PATH in general when building a buildout. (Though I don't know if buildout does that currently.)

I think this could be done by passing --bindir to the libxslt configure script in the cmmi recipe, might be nice as the default for the recipe. It didn't look like the buildout's bin was in PATH during the buidlout to me, but I agree it would be good if it was. - Luke

Ian Bicking wrote:

Luke Tucker wrote:

...

I wound up pushing parts/libxslt/bin onto the front of PATH with a recipe before calling lxmls setup, but there may be cleaner ways. There is a separate issue I mentioned in "lxml setup.py exslt link flag" related to doing this but I haven't gotten back to this yet to write a patch.

Why doesn't xml-config go in the top-level bin/ directory? It seems like that path should also be on the front of PATH in general when building a buildout. (Though I don't know if buildout does that currently.)

Hm, currently the 'bin' is only for scripts that are the *result* (and goal) of the buildout. The goal of the buildout is not to install the libxml2 tools, but it's to install lxml. libxml2 is only a step along the way for this. I also don't believe buildout does anything to PATH whatsoever (or that it by itself should - it goes out of its way to be very explicit about paths everywhere after all). I think it would help us a lot if lxml's setup.py simply accepted an option that identifies which xslt-config to use. This could be easily be configured from the buildout. Note that lxml's setup does something (what I don't know) when it's called with --rpath, another thing that buildout calls. Does it do the right thing? Regards, Martijn

Stefan Behnel wrote:

Hi Martijn,

Martijn Faassen wrote:

...

I think it would help us a lot if lxml's setup.py simply accepted an option that identifies which xslt-config to use. This could be easily be configured from the buildout.

Note that lxml's setup does something (what I don't know) when it's called with --rpath, another thing that buildout calls. Does it do the right thing?

See here, might be the right thing:

http://codespeak.net/pipermail/lxml-dev/2006-June/001528.html

I see that this discussion lead to the contribution of the path that adds the --rpath support. I suspect that this may be doing the right thing, but we need a way to configure the system to pick up a list of xslt_libs from a xslt-config in a custom location. Regards, Martijn