Subversion instructions/dependencies

Chris Staub chris at beaker67.com
Mon Apr 10 16:47:35 PDT 2006


Randy McMurchy wrote:
> 
> That ticket is closed and nothing in it gives me any clue what you
> are requesting. All I can see is that you didn't pass --without-expat
> so that it wouldn't look for it. I'm not sure that would help your
> situation, because I don't fully understand your situation.

If I try to pass "--without-expat" all I get is a a message that 
configure failed and "expat cannot be disabled at this time".

> Neon now uses Expat by default, and you have to go out of your way
> so that it is not used.

Here is the specific issue...

If I have neither libxml2 nor expat installed, neon will use the expat 
library in svn's source dir. If I install expat but not libxml2, neon 
will, by default, use the expat library already installed on my system. 
If I have libxml2 but not expat installed, and pass "--with-libxml2" to 
configure, neon still uses the expat in the source dir. If I have both 
libxml2 and expat installed on the system, and pass "--with-libxml2" to 
configure, neon does in fact use libxml2.

I attempted looking at the configure scripts, and from what little I 
know it seems that the main subversion configure script looks for expat 
already installed on the system, then if expat isn't found, it passes a 
parameter to the neon configure script telling it to use the expat in 
the subversion source dir, and as a result it doesn't even bother 
checking for libxml2. However, if you *do* have expat installed, this 
doesn't happen, so the neon configure script *will* look on it own for 
both expat and libxml2, and will honor "--with-libxml2". Neon itself is 
perfectly capable of easily using libxml2...it's just that the main 
subversion configure system, for some reason, seems to want to make it 
difficult to use.

If I pass "--with-libxml2" to configure, and have libxml2 installed, why 
shouldn't I expect it to be used? Basically, it's not acting as 
expected, and that should be documented. Also, it is the general policy 
of LFS to prefer system-installed libs over the same libs included in 
other packages' source dirs (both to save space, and to ensure that you 
have a good, recent version).



More information about the blfs-dev mailing list