On Tue, Sep 30, 2008 at 8:55 AM, Derek Scherger <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel