On 4/2/07, Ivan Zhakov <chemodax@gmail.com> wrote:
>
> Everybody knows that Subversion windows build system is messy. One of
> reason is external libraries that we trying to build automatically
> during Subversion build.
> Actually we have inconsistency: some libraries build automatically and
> some doesn't. Also for some libraries we provide precompiled binaries
> and for some don't.
>
> For present time status is:
> - apr, apr-util, apr-iconv build automatically. No precompiled binaries.
> - neon builds automatically.
> - serf builds automatically
> - zlib builds automatically
> - Berkley DB has to build manually, but we provide precompiled binaries.
> - sqlite has to build manually
> - openssl has to build manually (actually we don't use openssl
> directly, we use it
> through neon library)
> - gettext has to manually, we provide patched precompiled binaries
> - libsasl -- I don't know
>
> From my experience, most problems, that I had with building
> Subversion, caused by external libraries.
>
> I propose to remove automatic building of external libraries from
> Subversion windows build system.
> It better for us to focus on:
> - checking for problems in gen-make.py
> - improve building process of some libraries
> - provide precompiled binaries of libraries, like we did for bdb
> - provide batch scripts for building external libraries
> But don't build external libraries using generated project files from
> Visual Studio.
Won't that be putting too much pressure on us to provide different versions
built with different compilers? "I need APR 1.2.x compiled with VS 2005,
and I need it right away!" "Where do I get the binary for the latest Neon
release with SSPI enabled and built with VC 6.0?"
I'd rather see us enhance the build, assuming it cannot do this already, so
that it can accept pre-compiled binaries for these other pieces. And then
we could provide a default set or something. But it should still be
relatively easy for the user to build stuff from source without having to
stitch it all together themselves.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Mon Apr 2 22:11:27 2007