On 7/9/07, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> On 7/9/07, Dan Christian <dchristian@google.com> wrote:
> > My complaint is that I should never have to know to find/read the
> > neon, serf, and openssl docs to properly link against subversion
> > libraries! This should all be sanity checked at the subversion level
> > (configuration and/or run time).
>
> You would rather that we duplicate all documentation on the myriad
> ways you can configure each of our dependencies? Yes, our docs could
> be better on some of the common gotchas, and if you contributed a FAQ
> on how to get things perfectly happy in a multithreaded build or a
> patch to do the required runtime checking I'm sure it would be
> committed, but expecting to never have to refer to the docs for one of
> the packages that are required is really kind of a tall order, IMO.
Duplicating all the docs wouldn't get to the point.
./configure should take something like a ---with-threads=posix
argument and make a point to check the neon/serf/openssl build
configurations for the proper compile options.
This doesn't appear to be possible now, but "neon-config --support
posix-threads" would be the basic idea. serf would have to grow a
serf-config.
It would also be really, really great if we could verify that all the
different libraries are built against the same APR version.
There is a point behind all of this whining. Remember that (to me)
neon/serf/openssl are just requirements to get subversion built. I
don't understand them and I don't want to spend the time to become an
expert in configuring them.
If subversion gets built wrong, it behaves badly. Sure, it's probably
my fault, but it's subversion that dumps core. Just one more aspect
of library dependency hell.
I've attached my build script if anyone wants to either comment on it
or turn it into a FAQ. I have to build 5 things before I build
subversion. Part of this is because I have no way to tell if the
system supplied versions are built right.
-Dan C
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 9 22:18:44 2007