Re: neon build issues (long)

On Fri, Sep 01, 2000 at 11:30:34AM -0500, Ben Collins-Sussman wrote:
>...
> When I run ./autogen.sh, the script politely gives me instructions on
> how to check out apr and neon. No problem, I do so, and run
> ./autogen.sh again -- it finishes cleanly, creating `configure'
> scripts for the top-level and for apr/.

(FYI) Note: Neon comes with a prebuilt configure (unlike APR), so we don't
generate a configure in there. It will probably be just remain as SVN itself
and APR where we generate a configure script.

> Then I run ./configure on the top level; subversion and expat-lite
> directories get configured (Makefiles are created) -- but not apr.
> This is the first oddity. I assume this is fixable later by simply
> telling the top-level `configure.in' to run `./configure' inside
> apr/. (If I recall, we had this behavior turned off for convenience
> purposes.)

I added this last night or earlier today (I forget). Do the following:

    ./configure --enable-subdir-config

It will then go and run configure in the subdirs with all the correct magic
switches. Specifically, it will pass the top-level command line switches to
the subdir. For example, if you pass --with-maintainer-mode to the
top-level, then APR will also get it (and it recognizes it!). Neon will
receive the --disable-shared switch and understand it. etc.

Other neat trick: the config.cache file is *SHARED* between SVN, APR, and
Neon. It speeds things up quite a bit :-)

Also, very important: when it configures Neon, it uses the new switch that I
patched into Neon. That switch (--with-expat=../expat-lite) will point Neon
at the packaged Expat.

The patch is appended in clear text at the end of this message.

> So temporarily, I cd into apr/ and run `./configure'... all set there.
>
> Now I'm back at the top level, and run `make' on Linux (or `gmake' on
> FreeBSD).
>
> *** CHOKE ***. "Required file `ChangeLog' not found." Huh? What's
> that all about?

Beats me. Some automake thingy, I believe.

> I touch the file, and run `make' again:
>
> * apr/ builds ok (resulting in libapr.a)
> * expat-lite/ builds ok, (resulting in a libtool object, libexpat.la)
> * neon/ chokes. Why? Oh, oops, it was never configured!

See above :-)

> No problem. I cd into neon/ and run `./configure'.
>
> *** CHOKE ***. Neon's configure script dies, because `no XML parser
> found'.

My patch is needed, then the configure script needs to be rebuilt (using
autoconf). However, running autoconf is probably going to blow up on many
machines: Neon's requires GNOME and GTK to be installed (I don't know the
specific, minimum packages, but that's what it looks like).

When Joe applies my patch (hopefully, he will!), then this bogon will go
away cuz Neon will ship with a correct ./configure script.

To work around the problem, I deleted neon/macros/gnome-x-checks.m4 and
commented out the AM_PATH_LIBGLADE on line 61 in neon/configure.in.

> After a bit of experimentation, I notice that this second CHOKE only
> happens on Karl's Debian 2.1 machine, not on my FreeBSD box.
> Apparently neon is looking for libxml in a system path; after
> upgrading Karl's system libxml to a newer version, neon's ./configure
> finishes without complaint.
>
> (So, is this is a bug?

Maybe. I'll point Joe at this mail note; he can decide whether he wants to
call it a bug or simply shrug and say "upgrade" :-)

> Is libxml an assumed standard on every Free OS?

Nope. It will also look for Expat in standard places.

> Maybe neon's configure script needs to be more specific about
> exactly what version it needs?)

With my patch, we can point Neon at our bundled Expat and be done with the
problem.

> So I now go back to the project's top-level, and run `make' again.
> The make program builds `all' in apr/ successfully, builds `all' in
> expat-lite/ successfully, and then stops in neon/:
>
> *** CHOKE ***.
>
> Making all in neon
> gmake[2]: Entering directory `/usr/home/sussman/projects/subversion/neon'
> gmake[2]: *** No rule to make target `all'. Stop.

My patch (see below) fixed this one as well :-)

> Now, I'm not sure how to dissect this problem. I don't know why
> `make' is specifically trying to specifically build target `all' in
> each subdir...

Can you say "automake" ?

> but whatever the case, neon's autoconfiscation doesn't
> create this target. My guess is that either we can work around this
> by instructing our top-level configure.in to build a *different*
> target in neon/; or maybe Joel's Makefile.in isn't compliant in some
> GNU-ey or automake-ey way. Can someone shed light on this?

Adding the "all" target makes it easier to embed Neon into an automake-based
target. I think Joe will be quite happy to fold that in. He might have a
slightly different take on the expat switch, but probably won't have any
issues folding that in, either.

> For now, the only solution is to cd into neon/, and run `make' by
> hand, and then cd into subversion/ and do the same. Ick.
>
> Feedback from those who know automake/autoconf (better than I do)
> would be appreciated!

Heh. If something doesn't work, then go fix it to make it smoother. One line
in a makefile fixed the "make" problem. This is Open Source! You can fix it
yourself. Take charge!

:-)

I've also done some more autoconf work on SVN lately. It is getting better.

One last problem with the Neon integration: neon/libneon.la has a line about
"dependency_libs='...'". The contents refer to -L../expat-lite -lexpat.
Unfortunately, when we link against Neon (using libtool), it finds that line
and adds it to the link line. Well... ../expat-lite certainly doesn't work
when you're way the heck down in libsvn_ra_dav/tests/. I just eliminated the
stuff from dependency_libs and had my test program link against Expat.

Summary: after building Neon, tweak that in libneon.la to read:
dependency_libs=''

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
--- neon-0.7.0/Makefile.in	Sat Aug 12 08:53:58 2000
+++ neon/Makefile.in	Tue Aug 29 20:17:13 2000
@@ -90,6 +90,8 @@
 .c.o:
 	$(COMPILE) -c $< -o $@
 
+all: libneon.la
+
 libneon.la: $(OBJECTS)
 	$(LINK) -rpath $(libdir) -version-info $(NEON_INTERFACE_VERSION) -o $@ $(LDFLAGS) $(OBJECTS) $(LIBS)
 	@echo
--- neon-0.7.0/macros/neon-xml-parser.m4	Fri Jul 28 03:41:53 2000
+++ neon/macros/neon-xml-parser.m4	Tue Aug 29 20:04:32 2000
@@ -34,6 +34,25 @@
 	[neon_force_libxml=$enableval],
 	[neon_force_libxml=no])
 
+AC_ARG_WITH(expat,
+	[  --with-expat=DIR        use this to specify a directory where Expat
+	                          includes and libraries can be found.],
+[
+	if test "$withval" != "no"; then
+		if test -n "$withval/xmlparse.h"; then
+			AC_DEFINE(HAVE_EXPAT, 1, [Define if you have expat])
+			CFLAGS="$CFLAGS -I$withval"
+			LIBS="$LIBS -L$withval -lexpat"
+
+			neon_xml_parser_message="expat in $withval"
+			neon_found_parser="yes"
+		fi
+	fi
+],[
+	neon_found_parser="no"
+])
+
+if test "$neon_found_parser" = "no"; then
 if test "$neon_force_libxml" = "no"; then
 dnl Look for expat
 AC_CHECK_LIB(expat, XML_Parse,
@@ -43,8 +62,7 @@
 		neon_found_parser="no",
 		-lxmltok )
 	)
-else
-	neon_found_parser="no"
+fi
 fi
 
 if test "$neon_found_parser" = "no"; then