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