On 4/2/07, Ivan Zhakov <firstname.lastname@example.org> wrote:
> On 4/3/07, Mark Phippard <email@example.com> wrote:
> > On 4/2/07, Ivan Zhakov <firstname.lastname@example.org> 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
> > > - neon builds automatically.
> > > - serf builds automatically
> > > - zlib builds automatically
> > > - Berkley DB has to build manually, but we provide precompiled
> > > - 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
> > built with different compilers? "I need APR 1.2.x compiled with VS
> > and I need it right away!" "Where do I get the binary for the latest
> > release with SSPI enabled and built with VC 6.0?"
> > I'd rather see us enhance the build, assuming it cannot do this already,
> > that it can accept pre-compiled binaries for these other pieces. And
> > 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
> > stitch it all together themselves.
> We can provide pre-compiled binaries only for default configuration.
> And user can rebuild required external project, after getting similiar
> with Subversion project.
> Problem with current build system that it's very complex and each
> enhancement increase complexity :)
OK, so the default is probably VC 6.0? Now some new user comes along and
wants to use VS Express. Are we going to provide manual build instructions
for each dependency? I know the answer to that one. Basically, we are
going to make it even harder to get started.
If we committed to providing a VC 6.0 and VS 2005 pre-compiled binaries,
that would be the answer I think. It would be nice to provide APR 0.9 and
1.2 versions too, but I could live with just 0.9.
Received on Mon Apr 2 22:29:32 2007