On Wed, Apr 9, 2008 at 1:02 PM, Markus Schiltknecht <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel