Jeff Trawick wrote:
Modified: apr/apr-util/trunk/buildconf
URL:
http://svn.apache.org/viewcvs/apr/apr-util/trunk/buildconf?rev=374805&r1=374804&r2=374805&view=diff
==============================================================================
--- apr/apr-util/trunk/buildconf (original)
+++ apr/apr-util/trunk/buildconf Fri Feb 3 17:14:55 2006
@@ -38,8 +38,7 @@
shift
done
-if test -d "$apr_src_dir"
-then
+if [ -f "$apr_src_dir/build/apr_common.m4" ]; then
This type of construct isn't used in the generated configure (my lame
litmus test for whether it is portable). Is it safe everywhere?
It's not used in any .m4 / configure.in becase autoconf steals the [ ] as
quoting characters; therefore I did not use the construct, even with escaped
[ ]'s - in my .m4 & configure patches.
It's used elsewhere in our .sh scripts so I'd presumed portability - and it
seems to work reliably with linux bash and solaris sh (ksh).
In fact these were the only occurances of test in buildconf.sh - the other
occurances were already all [ ] 's.
else
@@ -84,17 +83,9 @@
$apr_src_dir/build/gen-build.py make
#
-# If apr-iconv, then go and configure it.
-#
-if test -d ../apr-iconv; then
- echo "Invoking ../apr-iconv/buildconf.sh ..."
- (cd ../apr-iconv; ./buildconf)
-fi
You quoted this, didn't know if you are looking for an explanation so I'll
provide it; right now we don't buildconf the ../apr tree from apr-util; it seems
very inconsistent to buildconf the ../apr-iconv tree and not ../apr. Reversing
the most recent change seemed the most appropriate.
In my illustration below, on solaris 10, looking up and over from ./apr/ to
../apr-util/ doesn't work (it's ../apr-util-0.9 - and I swear it's the buggiest
symlink behavior I've ever seen, but that's solaris shell ;-/) - so the patches
to httpd- and apr- are both ment to avoid that; the fullpath is determined in
httpd and passed to apr-util as ./buildconf --with-apr=/fullpath/to/apr-src
-#
# If Expat has been bundled, then go and configure the thing
#
-if test -d xml/expat; then
+if [ -f xml/expat/buildconf.sh ]; then
Curious: what does this change do?
Previously, if you replace xml/expat with a symlink to your local expat-1.9.8
source tree, for example, this test dies because a symlink isn't a dir.
Now, because the objective of this test is to invoke buildconf.sh - we test
for the presense of buildconf.sh - and ignore the distinction of whether
xml/expat happens to be a directory, or a symlink to a directory elsewhere.
It primarilly helps those of us frustrated with svn's failure-by-design to
descend into directories checked out from different repositories. In my test
and dev environment, for example, I have checked out...
build/
apr-0.9/
apr-util-0.9/
expat-0.9.8
httpd-2.0/
srclib/
apr -> /path/to/build/apr-0.9
apr-util -> /path/to/build/apr-util-0.9
xml/
expat -> /path/to/build/expat-0.9.8
etc...
with one
svn up apr-* httpd-*
I'm in sync. with one
svn diff apr-* httpd-*
I know all of the lingering patches. An example of how this is broken was
the small massage I made to the submittors patch for timeout_ms (to make the
quantum obvious to the reader) - and I had the same patch sitting in subdirs
of httpd-2.2 and 2.0, but didn't catch them before apr-0.9 was rolled because
svn isn't helpful in that regard :(
Bill
