Re: Outch, a few problems for 2.0/2.2
On 2/2/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Finally vpath + symlink builds were broken, there is a set of patches over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where -n.n is -2.0 -0.9, -2.2 -1.2, and -2.3 1.3 for the corresponding httpd and apr-util versions. The patches; * ensure we don't look for srclib/apr*** directories, but simply the file contained within. Seems reasonable to me... * avoid looking from apr-util to ../apr, since on symlinked environments in solaris this can be erronious. +1 * ensure we don't bomb on vpath builds looking for .h files in both the source and vpath target trees (because they don't exist in both). Consistently looking in one place seems reasonable. * properly check if we are vpath'ing for apr-util/xml/expat, creating that directory in the vpath target, and introduce the syntax --with-expat=builtin to resolve the ambiguity that vpath builds of the builtin expat introduces. Again, working in vpath builds is a good thing ;-) * never configure apr-iconv from apr-util. Since we won't configure apr from apr-util this was inconsistent. Assuming you mean buildconf, not configure, +1, I was surprised we did this at all. AFAICT the patches don't have anything to do with running apr-iconv's configure. In general the APR part of these patches looks reasonable to me, although I haven't actually tested them. Didn't look at the httpd side though. -garrett
Re: Outch, a few problems for 2.0/2.2
Garrett Rooney wrote: On 2/2/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Finally vpath + symlink builds were broken, there is a set of patches over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where -n.n is -2.0 -0.9, -2.2 -1.2, and -2.3 1.3 for the corresponding httpd and apr-util versions. The patches; * ensure we don't bomb on vpath builds looking for .h files in both the source and vpath target trees (because they don't exist in both). Consistently looking in one place seems reasonable. Actually the patch looks in both. We wrap that search in ( ) to avoid make (solaris make) discovering there was an error invoking ls ap[ru].u, for example, because those two files exist as generated objects on the target tree, not the source, while ap[ru]_*.h generally live on the source tree. * never configure apr-iconv from apr-util. Since we won't configure apr from apr-util this was inconsistent. Assuming you mean buildconf, not configure, +1, I was surprised we did this at all. AFAICT the patches don't have anything to do with running apr-iconv's configure. Right; long day yesterday, was in need of caffene replentishment.
Outch, a few problems for 2.0/2.2
1. We've really got to die on ./configure, not make, when we are asked to --enable-ldap where apr-util wasn't built with ldap. That's bogus; ./configure should describe anticipated problems, not later on. 2. Something's wrong with detection of ssl, even when I explicitly asked for /usr/local/ssl it's picking up /usr/sfw and I'm not yet sure why. (Both paths are passed, outch!) 3. We currently abspath the APR_UTIL_LIBS entry for /path-to/srclib/apr-util/xml/expat/lib/libexpat.la, but that seriously breaks my AIX vpath builds. I can guess we are trying to avoid picking up libexpat elsewhere in the -L list, but there's gotta be a better way for ordering this, and make it consistent 4. The libtool configs are pretty hokey. apr-util properly dereferences the apr libtool, why don't we do the same on our builtin expat? 5. Also hitting another abspath issue when trying to build apr-util and it's going for the absolute apr.la, working on that when I go back to AIX tomorrow. Finally vpath + symlink builds were broken, there is a set of patches over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where -n.n is -2.0 -0.9, -2.2 -1.2, and -2.3 1.3 for the corresponding httpd and apr-util versions. The patches; * ensure we don't look for srclib/apr*** directories, but simply the file contained within. * avoid looking from apr-util to ../apr, since on symlinked environments in solaris this can be erronious. * ensure we don't bomb on vpath builds looking for .h files in both the source and vpath target trees (because they don't exist in both). * properly check if we are vpath'ing for apr-util/xml/expat, creating that directory in the vpath target, and introduce the syntax --with-expat=builtin to resolve the ambiguity that vpath builds of the builtin expat introduces. * never configure apr-iconv from apr-util. Since we won't configure apr from apr-util this was inconsistent. Comments on the proposed patches so far?
