Re: [Monotone-devel] library build

[Zack Weinberg]

On Tue, Sep 30, 2008 at 8:55 AM, Derek Scherger <address@hidden> wrote:
> Is the idea of the library build branch to have monotone to build all of the
> libraries it needs, but do this by using each library's own build system or
> is it to get monotone to a state where it requires and uses system installed
> libraries?

The original idea was to have it build all of the libraries it needs
using each library's own build system, with the option to use system
installed libraries if desired by the builder.  I got hideously stuck
on this because it really needs to be set up in a way that automake
and autoconf aren't designed for -- someone mentioned upthread that
it's bizarre to invoke subdirectory configure scripts from the
makefile, and yes it is, but if this is what we want, *there is no
alternative*, because AC_CONFIG_SUBDIRS does not allow you to modify
the command line options.

It also became clear that there are still quite a few hacks that we
rely on in our local copies of the libraries.  The big one was, we
compile lua as C++ so its error handling turns into C++ exceptions.  A
system-provided liblua won't do this.  We don't do error propagation
across the lua/C++ interface correctly anyway (errors in lua hooks
have a bad way of just disappearing), so I would *like* to rip that
out and go back to lua's C interface, but I haven't had time.

It might make sense to start a new project to rip out our bundled
libraries altogether and then fix everything necessary to make it work
with system libraries.  In fact, I think that might be a good stepping
stone to a more sane way of bundling libraries, even if we do want to
keep doing that.  If we do start that project, though, it should use a
different branch than library-build, because they're very different
schemes and they'll trip over each other no end.

zw