On Jun 30, 2009, at 2:35 PM, Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tim Hoffman wrote: >> I have to chime in here too >> >> lxml is a real pain and seems to be problematic to get a >> straightforward >> build for packages other than ZTK as well. I have had varying >> success >> building lxml even under ubuntu - success seems to be dependant on >> the type >> of build defined. > > While I know that Mac people often report problems building lxml, I > never have issues building lxml on Linux: the '--static-deps' > option is > a sufficient workaround for variants with too-old versions of > libxml2 / > libxslt.
I'm not familiar with the static-deps option. To what? Its setup.py? It didn't install cleanly for me on Centos 4. (I've generally had difficulty with libxml2 and libxslt on Red Hat based systems,) I'm sure if I screwed around with it, I could get it to work. I don't want to screw around with it just to work on ZTK libraries, which don't actually depend on it. I will if I have to. I ended up using an Ubuntu VM to work on it. I'd prefer not to have to. I'm sad to say this. I think lxml is a worthy project. It's a shame that the system installs of libxml2 and libxslt are such a PITA. I wonder if it would be better for lxml to include it's own copies of these libraries that it built and linked against statically. Will lxml look somewhere in /usr/local? I wonder if hand-built libxml2 and libxslt libraries in /usr/local would make lxml easier to deal with. Jim -- Jim Fulton Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
