[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

neon build issues (long)

From: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2000-09-01 18:30:34 CEST

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

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

*** 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

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. :)
Received on Sat Oct 21 14:36:07 2006

This is an archived mail posted to the Subversion Dev mailing list.