Re: buildconf against installed APR
Luc Pardon wrote: Yes, that was precisely my point. I know of no other packages - except the kernel and (your version of) apr - that are installed by default in this way. For all other packages - to the best of my knowledge - rpm -U is the default way. It is not for naught that kernel upgrade how-to's warn explicitly to use -i and not -U. Therefore, users of your packages will install with -U out of habit, wipe out the v0.x version and hose up their systems. It's not what I call the principle of least surprise. Not true - if people have packages on their system that use apr v0.x, they will get a warning and rpm -U will fail. But you say that -i is normal, I say -U is normal, so we have no common ground here and neither of us would be able to supply hard figures to convince the other. You are missing the end goal of APR. APR v0.x will go away in time, and the plan is for this to happen sooner rather than later. If you come to the ASF for packages, you're going to get what we consider to be our best packages, and that at the moment is APR v1.x. Distro maintainers are likely to take a far more conservative approach, and stick to httpd v2.0 (and thus APR v0.9). We hope to change that over time. We are not going to change that however by bending over backwards to binary package v0.9.x. We want people to upgrade to httpd v2.2 and apr v1.x, that is why they are packaged as they are. If you consider that an ugly kludge, fine, that is your personal opinion. I don't believe it is documented as a kludge anywhere, so I consider it a matter of taste. Matters of taste are not to be the subject of discussion (as are colors and women, as any Ancient Roman would tell you ;-). In any case there are dozens of packages that use the same "kludge", including gtk, glib, qt, and many others. These are few examples of libraries that build major version numbers into their names, the vast majority don't. Besides, even if it is a kludge, it is only fitting, no ? (I mean the need to support two versions for a project as young as APR does not reflect positively on APR as a reuseable library.) For historical reasons, httpd v2.0 depends on apr v0.9. To say that this doesn't reflect positively on APR is meaningless, as this is an external dependancy from just one project (subversion will build against either v0.9 or version 1.x). the kernel way, the second is by publishing a "-compat" library for the old version. As "-compat" libraries typically don't have "-devel" I don't know what gave you that impression. A quick search on rpmfind.net or the like on "*compat*devel" turns up plenty of counter-examples. This seems only logical: a library without header files (which is what typically goes into -devel) is of limited use in an open source world. Ok, fair enough. But the purpose of the -compat library is to allow older packages that have not yet upgraded (eg httpd v2.0) to coexist beside the current preferred build (apr v1.x). But I do happen to agree that "compat" is not the right way, if for different reasons. With aprX you could have apr2 alongside apr0 and apr1, if/when needed. -compat is the way most distributions handle this issue when it arises. I am not saying that your httpd.spec file should build a binary httpd rpm that _contains_ the apr binaries. I am happy with separate packages (assuming that httpd is dependent on any apr 1.x and not on 1.2.2 specifically). httpd depends on a minimum level of APR like any binary RPM, it does not depend on a static snapshot of APR. I am saying that the httpd.spec file should build _separate_ binary apr and apr-util packages _from_the_same_tarball_. (I believe that I posted that here already, after running into this issue and asking here.) I disagree. The APR project should build and ship APR binaries as it sees fit. It stands alone from the httpd project, doing what you suggest is a step backwards. As you know (but others may not) one spec file can build several packages from a single tarball. The RedHat package file that you (and I) used as a starting point does this already: it builds httpd, httpd-devel, httpd-manual and mod_ssl rpm's. So why not apr and apr-util as well ? Because APR is a separate project that by design wants to be independant of httpd. Your answer will be: "because I will have to undo it when APR gets unbundled". APR has been unbundled a while ago. It exists in the httpd source tree for historical reasons. You'll notice Redhat and others don't build apr RPMs from httpd's SRPM, which is exactly the direction APR wants to take. And of course that is correct. And I also happen to agree that it should be unbundled sooner rather than later. But this has not happened, and it does not seem a priority for the developers either. It has quite a while ago - see the apr-devel archives for details. But on the other hand it is not that much work that would ha
Re: buildconf against installed APR
Hello Graham, It seems we'll have to agree to disagree as we obviously differ on fundamental interpretation. It's hardly a matter of much concern anyway, as most packagers will have their own spec file by now. Before withdrawing from this discussion I'd like to add some comments, if only for the benefit (?) of whoever else is reading this thread (if anybody). Graham Leggett wrote: > > Luc Pardon wrote: > > >> Both apr and httpd ship with generic spec files included. The apr spec > >> files are designed so that you can install apr-0.x and apr-1.x side by > >> side without conflicts, > > > >As far as the included apr spec files are concerned, this is simply > > not true. > > > >Last time I looked, the spec files for 0.9.7 and 1.2.2 use the same > > package names, i.e. apr and apr-util. > > To install two major versions of the same package, use the following to > install: > > rpm -i packagename.rpm > > Packages in the v0.x branch and the v1.x branches are designed not to > conflict with each other. > > For examples of another RPM package that is installed by default in this > way, see the kernel RPMs. > Yes, that was precisely my point. I know of no other packages - except the kernel and (your version of) apr - that are installed by default in this way. For all other packages - to the best of my knowledge - rpm -U is the default way. It is not for naught that kernel upgrade how-to's warn explicitly to use -i and not -U. Therefore, users of your packages will install with -U out of habit, wipe out the v0.x version and hose up their systems. It's not what I call the principle of least surprise. But you say that -i is normal, I say -U is normal, so we have no common ground here and neither of us would be able to supply hard figures to convince the other. > >But because of the name, rpm will consider apr-1.2.2 simply a later > > version of apr-0.9.7, exactly as told. Therefore if you install 1.2.2 it > > will obligingly _remove_ all the 0.9.7 stuff, including all the apr-0 > > dirs and their content. Bye-bye side-by-side. > > This will only happen if you use the rpm -U (meaning "upgrade") Which - to me - means that it will happen all the time. To you, it seems to mean that it will happen only in exceptional cases. Again, no common ground on an essential issue. > instead of rpm -i (meaning "install"). If you mean to say that they are opposed, I have to disagree, but here at least I can provide (some form of) proof. From man 8 rpm: [rpm -U ] is the same as install, except all other version(s) of the package are removed after the new package is installed. Note that is says "the same as". In fact, rpm -U is the same as -i if no previous version is present, and the same as rpm -F (--freshen) otherwise. Note also that it says "version(s)" (plural). If I read that correctly, you're heading for trouble even if you don't fall into the -U trap, more on that below. > > > tell me that, as a workaround, I can install > > with "rpm --install" instead of the normal "rpm --upgrade" or "rpm > > --freshen" but that is not standard, normally only used for kernel > > installs, and dangerous in just about all other cases. > > It's not dangerous at all, and quite standard. See the RPM docs for details. When I said "not standard", I meant "not usual". If you mean by "standard" that it is documented, I agree, it is. But so are the --nodeps, --ignoreos etc switches that let you bypass or disable the extra safety that rpm offers above a simple configure/make/make install sequence. That does not make them safe, unless you know exactly what you are doing. It's not because man 1 rm does not warn against rm -rf /* as root that it is "not dangerous at all" . If you are lucky, rpm -i will fail when you have an older version of the same package installed. This is because it won't overwrite files that have the same name. You would then have to do rpm -F (freshen). Most people won't bother and do -U right away and let rpm figure it out. This is one of the reasons why I said -U is "standard" and -i is not. Now, if the packager has changed his mind between releases and installs the new stuff - for example - into /usr/local whereas it was in /usr previously, you're out of luck: rpm -i will work and you'll end up with two versions in different dirs. Most packages have no need to install multiple versions and are not designed for side-by-side install. So you have a 50% chance that the wrong one will be picked up when compiling against it. Any developer knows what this means. This is why I say it is dangerous. rpm -U will prevent that from happening, and this is also the second reason why I said that -U is "standard". I say it is dangerous, you say it is not. Again, opinion, no common ground, no proof possible. Above I pointed out that the man page says that rpm -U will remove "other version(s)" (plural). I have never tried it, but it makes sense. So, im
Re: buildconf against installed APR
Luc Pardon wrote: Both apr and httpd ship with generic spec files included. The apr spec files are designed so that you can install apr-0.x and apr-1.x side by side without conflicts, As far as the included apr spec files are concerned, this is simply not true. Last time I looked, the spec files for 0.9.7 and 1.2.2 use the same package names, i.e. apr and apr-util. To install two major versions of the same package, use the following to install: rpm -i packagename.rpm Packages in the v0.x branch and the v1.x branches are designed not to conflict with each other. For examples of another RPM package that is installed by default in this way, see the kernel RPMs. But because of the name, rpm will consider apr-1.2.2 simply a later version of apr-0.9.7, exactly as told. Therefore if you install 1.2.2 it will obligingly _remove_ all the 0.9.7 stuff, including all the apr-0 dirs and their content. Bye-bye side-by-side. This will only happen if you use the rpm -U (meaning "upgrade") instead of rpm -i (meaning "install"). tell me that, as a workaround, I can install with "rpm --install" instead of the normal "rpm --upgrade" or "rpm --freshen" but that is not standard, normally only used for kernel installs, and dangerous in just about all other cases. It's not dangerous at all, and quite standard. See the RPM docs for details. And there is no need for a workaround either. The apr is not the only one that must be able to support multiple versions side-by-side. Standard practice is to use different package names by including the version number _in_ the package name (eg apr0 and apr1), as Oden correctly did. This is an ugly kludge. There are two techniques to handle this. One is the kernel way, the second is by publishing a "-compat" library for the old version. As "-compat" libraries typically don't have "-devel" packages, the kernel style install was chosen. As to the included httpd.spec, that is not "generic" either, if I may say so. As I pointed out a few weeks ago, it does not even build out of the box on a clean machine. To reiterate: it mandates a separate, pre-existing install of apr/apr-util or else it dies. That is the intention. The APR is a completely separate library, it has no business being binary packaged with httpd. If it is, how do you install a binary package of httpd+apr with a binary package of subversion+apr? You don't, as you get conflicts. APR is packaged in the httpd tarball for historical and convenience reasons for people building from source. The apr code is right there in the httpd tarball but it has no purpose as you can't use it, you have to go get apr rpm packages elsewhere. Either apr is bundled or it is not bundled, one can't have it both ways. You can. I know (or at least have the impression) that you feel strongly about the spec files that you contributed, and I don't want to offend. But there is definitely room for improvement, to say the least. A good spec file - especially if it comes with the product - should build everywhere, under any circumstances, not just on the author's machine (and please don't take this as a personal attack, it is not meant as one). If it doesn't build on your machine, I definitely want to hear about it, but so far it seems that it does build, the package just isn't arranged how you want it. I can assure you that a lot of thought has gone into the APR and the Solaris packaging, for the purpose of launching APR as the standalone package that it should be. There is a lot of precedence for the current layout (the RPMs were originally Redhat RPMs, with the patches and a lot of the file moving removed). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: buildconf against installed APR
fredagen den 2 december 2005 09.15 skrev Paul Querna: > Oden Eriksson wrote: > > torsdagen den 1 december 2005 23.56 skrev Sander Temme: > >> On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote: > >>> torsdagen den 1 december 2005 21.38 skrev Sander Temme: > Note the cp turds: those files are not installed along with APR, so > buildconf cannot copy them over. How come I or no one else noticed > this ever? Probably because these files are not cleaned up by make > >>> > >>> Because you never package it like we do. I think you only do ./ > >>> configure; > >>> make; make install and are satisfied with that. > >> > >> Oden, > >> > >> Can you tell us what steps you take to package httpd/apr/apr-util? I > >> think that would tell us a little more about possible use cases for > >> the build system. > >> > >> Thanks, > >> > >> S. > > > > Ok, will do. > > > > I publish the rpm spec files and I hope it won't be hard to understand > > them. > > > > Here are the spec files: > > > > http://nux.se/Cooker/SPECS/ > > > > And here are source and patches applied: > > > > http://nux.se/Cooker/SOURCES/ > > It would be good to merge in as many patches as possible that you apply > to our code base.. external patches are not good for anyone. > > -Paul OK. apr-0.9.3-deplibs.patch: - link libapr against libraries on which it depends - re-order link line so that -pthread can be passed down to the compiler driver with an appropriate LT_LDFLAGS Author: Joe Orton http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/apr-0.9.3-deplibs.patch apr-1.0.0-mutextype_reorder.diff: This one makes the mutext type set as default to fcntl because the implementation in the nptl in recent linux distros seems very unmature/unstable, especially if you use exotic CPU's (that does not present themselves as a i686 i think) and kernel 2.4.x with apr compiled on a Linux 2.6.x box against nptl. Well I guess that is Linux specific and won't make it into your codebase. Anyway it saves a lot of headaches... Author: Oden Eriksson http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/apr-1.0.0-mutextype_reorder.diff apr-1.1.0-config.diff: Removes not needed code from arp-config Author: Joe Orton http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/apr-1.1.0-config.diff apr-util-0.9.5-lib64.diff: - shuffle the find libname logic around a bit. In all the autofoo and m4 macros "/lib" is hardcoded, that should be fixed. I see now php has finally fixed it like this "--with-libdir=libfoo", maybe you can do it like that too? Author: Oden Eriksson http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/apr-util-0.9.5-lib64.diff apr-util-1.2.2-config.diff: Removes not needed code from arp-config Author: Joe Orton http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/apr-util-1.2.2-config.diff apr-util-1.2.2-postgresql.diff: This is needed in Mandriva, and possible in other distros too. It should be another test added. Author: Oden Eriksson http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/apr-util-1.2.2-postgresql.diff -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: buildconf against installed APR
> Both apr and httpd ship with generic spec files included. The apr spec > files are designed so that you can install apr-0.x and apr-1.x side by > side without conflicts, As far as the included apr spec files are concerned, this is simply not true. Last time I looked, the spec files for 0.9.7 and 1.2.2 use the same package names, i.e. apr and apr-util. True, there is a "%define aprver X" statement in the spec, and that will cause the contents of the rpm to go in separate apr-X directories. But because of the name, rpm will consider apr-1.2.2 simply a later version of apr-0.9.7, exactly as told. Therefore if you install 1.2.2 it will obligingly _remove_ all the 0.9.7 stuff, including all the apr-0 dirs and their content. Bye-bye side-by-side. I am sure you are gonna tell me that, as a workaround, I can install with "rpm --install" instead of the normal "rpm --upgrade" or "rpm --freshen" but that is not standard, normally only used for kernel installs, and dangerous in just about all other cases. And there is no need for a workaround either. The apr is not the only one that must be able to support multiple versions side-by-side. Standard practice is to use different package names by including the version number _in_ the package name (eg apr0 and apr1), as Oden correctly did. As to the included httpd.spec, that is not "generic" either, if I may say so. As I pointed out a few weeks ago, it does not even build out of the box on a clean machine. To reiterate: it mandates a separate, pre-existing install of apr/apr-util or else it dies. The apr code is right there in the httpd tarball but it has no purpose as you can't use it, you have to go get apr rpm packages elsewhere. Either apr is bundled or it is not bundled, one can't have it both ways. I know (or at least have the impression) that you feel strongly about the spec files that you contributed, and I don't want to offend. But there is definitely room for improvement, to say the least. A good spec file - especially if it comes with the product - should build everywhere, under any circumstances, not just on the author's machine (and please don't take this as a personal attack, it is not meant as one). Best regards, Luc Pardon
Re: buildconf against installed APR
Oden Eriksson wrote: torsdagen den 1 december 2005 23.56 skrev Sander Temme: On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote: torsdagen den 1 december 2005 21.38 skrev Sander Temme: Note the cp turds: those files are not installed along with APR, so buildconf cannot copy them over. How come I or no one else noticed this ever? Probably because these files are not cleaned up by make Because you never package it like we do. I think you only do ./ configure; make; make install and are satisfied with that. Oden, Can you tell us what steps you take to package httpd/apr/apr-util? I think that would tell us a little more about possible use cases for the build system. Thanks, S. Ok, will do. I publish the rpm spec files and I hope it won't be hard to understand them. Here are the spec files: http://nux.se/Cooker/SPECS/ And here are source and patches applied: http://nux.se/Cooker/SOURCES/ It would be good to merge in as many patches as possible that you apply to our code base.. external patches are not good for anyone. -Paul
Re: buildconf against installed APR
Oden Eriksson wrote: I publish the rpm spec files and I hope it won't be hard to understand them. Here are the spec files: http://nux.se/Cooker/SPECS/ And here are source and patches applied: http://nux.se/Cooker/SOURCES/ Both apr and httpd ship with generic spec files included. The apr spec files are designed so that you can install apr-0.x and apr-1.x side by side without conflicts, and the httpd one depends on apr-1.x. If you look at these files (httpd.spec/apr.spec in the root of the tarball) it should give you an example to work from of how to get apr to play nice with httpd. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: buildconf against installed APR
fredagen den 2 december 2005 02.54 skrev Oden Eriksson: > torsdagen den 1 december 2005 23.56 skrev Sander Temme: > > On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote: > > > torsdagen den 1 december 2005 21.38 skrev Sander Temme: > > >> Note the cp turds: those files are not installed along with APR, so > > >> buildconf cannot copy them over. How come I or no one else noticed > > >> this ever? Probably because these files are not cleaned up by make > > > > > > Because you never package it like we do. I think you only do ./ > > > configure; > > > make; make install and are satisfied with that. > > > > Oden, > > > > Can you tell us what steps you take to package httpd/apr/apr-util? I > > think that would tell us a little more about possible use cases for > > the build system. > > > > Thanks, > > > > S. > > Ok, will do. > > I publish the rpm spec files and I hope it won't be hard to understand > them. > > Here are the spec files: > > http://nux.se/Cooker/SPECS/ > > And here are source and patches applied: > > http://nux.se/Cooker/SOURCES/ Ahh, I'm tired, I should have pointed in the right direction: http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr1/ http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/libapr-util1/ :-) -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: buildconf against installed APR
torsdagen den 1 december 2005 23.56 skrev Sander Temme: > On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote: > > torsdagen den 1 december 2005 21.38 skrev Sander Temme: > >> Note the cp turds: those files are not installed along with APR, so > >> buildconf cannot copy them over. How come I or no one else noticed > >> this ever? Probably because these files are not cleaned up by make > > > > Because you never package it like we do. I think you only do ./ > > configure; > > make; make install and are satisfied with that. > > Oden, > > Can you tell us what steps you take to package httpd/apr/apr-util? I > think that would tell us a little more about possible use cases for > the build system. > > Thanks, > > S. Ok, will do. I publish the rpm spec files and I hope it won't be hard to understand them. Here are the spec files: http://nux.se/Cooker/SPECS/ And here are source and patches applied: http://nux.se/Cooker/SOURCES/ -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: buildconf against installed APR
On Dec 1, 2005, at 1:03 PM, Oden Eriksson wrote: torsdagen den 1 december 2005 21.38 skrev Sander Temme: Note the cp turds: those files are not installed along with APR, so buildconf cannot copy them over. How come I or no one else noticed this ever? Probably because these files are not cleaned up by make Because you never package it like we do. I think you only do ./ configure; make; make install and are satisfied with that. Oden, Can you tell us what steps you take to package httpd/apr/apr-util? I think that would tell us a little more about possible use cases for the build system. Thanks, S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: buildconf against installed APR
torsdagen den 1 december 2005 21.38 skrev Sander Temme: > Note the cp turds: those files are not installed along with APR, so > buildconf cannot copy them over. How come I or no one else noticed > this ever? Probably because these files are not cleaned up by make Because you never package it like we do. I think you only do ./configure; make; make install and are satisfied with that. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
buildconf against installed APR
OK, I've been poking at the buildconf script a little bit. The following patch: Index: buildconf === --- buildconf (revision 351458) +++ buildconf (working copy) @@ -53,24 +53,32 @@ # should_exit=0 -apr_found=0 -apu_found=0 +apr_found="no" +apu_found="no" for dir in $apr_src_dir do -if [ -d "${dir}" -a -f "${dir}/build/apr_common.m4" ]; then -echo "found apr source: ${dir}" -apr_src_dir=$dir -apr_found=1 -break +if [ -d "${dir}" ]; then +if [ -f "${dir}/build/apr_common.m4" ]; then +echo "found APR source: ${dir}" +apr_src_dir=$dir +apr_found="source" +break +fi +if [ -f "${dir}/bin/apr-1-config" ]; then +echo "found installed APR in: ${dir}" +apr_src_dir=$dir +apr_found="binary" +break +fi fi done -if [ $apr_found -lt 1 ]; then +if [ x$apr_found = "xno" ]; then echo "" -echo "You don't have a copy of the apr source in srclib/apr. " +echo "You don't have a copy of the Apache Portable Runtime version 1.x. " echo "Please get the source using the following instructions," -echo "or specify the location of the source with " +echo "or specify the location of an installed copy with " echo "--with-apr=[path to apr] :" echo "" echo " svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr" @@ -80,19 +88,27 @@ for dir in $apu_src_dir do -if [ -d "${dir}" -a -f "${dir}/Makefile.in" ]; then -echo "found apr-util source: ${dir}" -apu_src_dir=$dir -apu_found=1 -break +if [ -d "${dir}" ]; then +if [ -f "${dir}/Makefile.in" ]; then +echo "found APR-Util source: ${dir}" +apu_src_dir=$dir +apu_found="source" +break +fi +if [ -f "${dir}/bin/apu-1-config" ]; then +echo "found installed APR-Util in: ${dir}" +apu_src_dir=$dir +apu_found="binary" +break +fi fi done -if [ $apu_found -lt 1 ]; then +if [ x$apu_found = "xno" ]; then echo "" -echo "You don't have a copy of the apr-util source in srclib/apr- util. " +echo "You don't have a copy of the APR Utility Library version 1.x. " echo "Please get one the source using the following instructions, " -echo "or specify the location of the source with " +echo "or specify the location of installed copy with " echo "--with-apr-util=[path to apr-util]:" echo "" echo " svn co http://svn.apache.org/repos/asf/apr/apr-util/ trunk srclib/apr-util" @@ -128,22 +144,23 @@ cross_compile_warning="warning: AC_TRY_RUN called without default to allow cross compiling" -if [ -d srclib/apr ]; then +if [ x$apr_found = "xsource" ]; then echo rebuilding $apr_configure -(cd srclib/apr && ./buildconf) || { +(cd ${apr_src_dir} && ./buildconf) || { echo "./buildconf failed for apr" exit 1 } -rm -f srclib/apr/apr.spec +rm -f ${apr_src_dir}/apr.spec fi -if [ -d srclib/apr-util ]; then +if [ x$apu_found = "xsource" ]; then +abs_apr_src_dir=$(cd "${apr_src_dir}" && pwd) echo rebuilding $aprutil_configure -(cd srclib/apr-util && ./buildconf) || { +(cd ${apu_src_dir} && ./buildconf --with-apr=${abs_apr_src_dir}) || { echo "./buildconf failed for apr-util" exit 1 } -rm -f srclib/apr-util/apr-util.spec +rm -f ${apu_src_dir}/apr-util.spec fi echo copying build files (also attached) gets rid of all the hardcoded references to srclib/apr {,-util}, recognizes an installed copy vs. a source tree and builds configure only in the latter case. However, I keep running into problems: [EMAIL PROTECTED] trunk $ ./buildconf --with-apr=/Volumes/Files/ asf/apr-1.2.x --with-apr-util=/Volumes/Files/asf/apr-1.2.x found installed APR in: /Volumes/Files/asf/apr-1.2.x found installed APR-Util in: /Volumes/Files/asf/apr-1.2.x copying build files cp: /Volumes/Files/asf/apr-1.2.x/build/find_apu.m4: No such file or directory cp: /Volumes/Files/asf/apr-1.2.x/build/find_apr.m4: No such file or directory cp: /Volumes/Files/asf/apr-1.2.x/build/apr_common.m4: No such file or directory cp: /Volumes/Files/asf/apr-1.2.x/build/PrintPath: No such file or directory cp: /Volumes/Files/asf/apr-1.2.x/build/config.sub: No such file or directory cp: /Volumes/Files/asf/apr-1.2.x/build/config.guess: No such file or directory rebuilding srclib/pcre/configure rebuilding include/ap_config_auto.h.in rebuilding configure rebuilding rpm spec file fixing timestamps for mod_ssl sources Note the cp turds: those files are not installed along with APR, so buildconf cannot copy them over. How come I or no one else noticed this ever? Probably because these files are not cleaned up by make distclean and ignored by svn, so they sti