monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] library-build progress report and request for help


From: Zack Weinberg
Subject: Re: [Monotone-devel] library-build progress report and request for help with botan
Date: Wed, 9 Apr 2008 14:14:04 -0700

On Wed, Apr 9, 2008 at 1:02 PM, Markus Schiltknecht <address@hidden> wrote:
>  Trying that setup, I've been puzzled about all the steps needed. I still
> don't get warm with the mixture of the configuration step and the actual
> building step. However, that might just be personal preference.

It is unusual, but I see no alternative, given that we must be able to
control the command line switches passed to subdirectory configure
scripts, and AC_CONFIG_SUBDIRS has no support for this.  (Also,
AC_CONFIG_SUBDIRS does not know how to run botan's configure.pl
correctly.)

I also think that the configure script for the monotone subdirectory
will be simpler if it is run after the (enabled subset of the) bundled
libraries are installed to the staging directory, but as I haven't yet
revised that script, I don't know for sure.

>   * I've spent some time to figure out that I needed to run aclocal for
> every subdir. Only later on, I've noticed that there's an autogen.sh script
> which does that for me. However, as INSTALL still recommends running aclocal
> manually, that might entrap other users as well.

I intended to edit INSTALL only after everything was done, but we can
certainly change it now if you think that's more useful.

(You mean autoreconf, right?)

>   * If pcre's configure script fails after having created pcre/Makefile (for
> example due to missing config.h.in), a subsequent 'make pcre/Makefile' won't
> restart configure for pcre, because the Makefile is up-to-date. Maybe simply
> add more of the files there as dependencies, so that make reruns pcre's
> configure.

I didn't do that only because I get a headache if I try to write down
the set of rules that would be necessary, and I thought I could get
away with not doing it yet.

>   * Botan's 'make install' complains about ownership problems:

Jack's fixed this upstream, but for now you can do 'make install
USER=u GROUP=g' where u and g are your username and primary group,
respectively.  I mean to put that into the top-level Makefile until a
new botan comes out.

>  Do we really need to run 'make install' for these 3rdparty libraries?

Yes.  If we instead use -I to pick up headers from the source tree,
builds with the bundled libraries will be able to see library-internal
headers, whereas builds with system libraries won't; this is asking
for trouble.  Also, running 'make install' means that the monotone
subdirectory doesn't have to know anything about the structure of the
bundled library subdirectories; it just does -I libinst/include -L
libinst/lib and it's happy.

> Having top-level 'make' recurse into all of subdirs running 'make install'
> every time seems expensive to me.

This is what libinst/*-stamp are for.  A second 'make' at top level
shouldn't recurse.  Of course, we need real dependencies for those so
that it does rebuild a subdirectory that's changed, but again, that is
something I thought I could get away with implementing later.

>  After having worked around these issues, I've been able to run 'make' and
> 'make install' in all of the subdirectories (lua, botan, pcre, netxx, idna
> and sqlite).

Cool beans.  Did you get the autoconf tests that are for sqlite's
benefit out of monotone/configure.ac and into the stub
sqlite/configure.ac, or did you drop in the upstream sqlite build
harness, or?  A nice next-action would be to get botan and sqlite's
internal testsuites imported and working.

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]