Re: neon build issues (long)

I've got Neon building better (posted a patch to Joe a couple days ago for
this), and was intending to write an email about it last night... Ended up
not getting to it.

I'll send something in a little while; got some errands to do first.

At a minimum, see my post to the neon mailing list at
    http://mailman.webdav.org/pipermail/neon/

Cheers,
-g

On Fri, Sep 01, 2000 at 11:30:34AM -0500, Ben Collins-Sussman wrote:
>
> I'm noticing some build integration problems, so I'm trying to
> summarize status of things from a top-down view, what a new developer
> would experience after checking out subversion. I hope folks can
> advise on fixing these things.
>
> So far, there are four top-level subdirs that must be built in our
> subversion working copy:
>
> * apr
> * expat-lite
> * neon
> * subversion
>
> When I check out the project, I get the expat-lite and subversion
> subdirs automatically. They're fully integrated into the top-level
> automake and autoconf. (Thanks, Greg!)
>
> 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/.
>
> 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.)
>
> 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?
>
> 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!
>
> No problem. I cd into neon/ and run `./configure'.
>
> *** CHOKE ***. Neon's configure script dies, because `no XML parser
> found'.
>
> 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? Is libxml an assumed standard on every Free
> OS? Maybe neon's configure script needs to be more specific about
> exactly what version it needs?)
>
> 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.
>
> 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... 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?
>
> 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!
>
>
> -Ben, CollabNet Testing Labs. :)

-- 
Greg Stein, http://www.lyra.org/