apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r374805 - in /apr/apr-util/trunk: CHANGES build/apu-conf.m4 buildconf
Date Sat, 04 Feb 2006 17:57:31 GMT
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

Mime
View raw message