Well, it doesn't work if you don't call your APR install apr. If it's called apr-0.9.2, it works. If it's called, say, httpd-2.0.44-dev, it won't work.As I posted yesterday, generation of exports.c is busted without srclib/apr and srclib/apr-util.If you can get it to work with just the buildconf change, I'd love to see it.
The APR_INCLUDES sed line configure.in is just plain wrong. I've got some local fixes that will take care of that (too late for me to get it all tested tonight). Furthermore, I'm not even sure that we should be accounting for the exports on an already installed APR. But, perhaps we could leverage apr.exp somehow.
The killer problem is the httpd-2.0.44-dev case which already has a prior install of httpd in it. The compiler just goes crazy if you try to compile httpd with old httpd headers in your path. Not good. (exports.c actually chokes on this case too because of duplicate symbols.) Would we even want to support this case?
I'd rather release something where even an edge case works because this is just such a major problem that we haven't been allowing for any type of separate installs. If it takes another 3 months for a 2.0 release, then I think the buildconf fix should go in knowing the caveat that the install must have 'apr' somewhere in the string. At the very least, we can give our users something to work with. In the next 2.0 release, we can target getting it better. -- justin
