apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Hudson <ghud...@MIT.EDU>
Subject Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
Date Thu, 01 Jul 2004 22:44:45 GMT
Joe Orton wrote:
> If apr-config is not renamed in the 0.9 branch (which is really
> required for compatibility), then I guess yes, make the argument
> optional, and have logic:

>   AP?_FIND_AP?(without extra version argument)
>    => use apr-1-config if found else apr-config if found

>   AP?_FIND_AP?(requires version N)
>    => use apr-N-config if found else no fallback

I may not be understanding all of the constraints.  Can you tell me
what goes wrong with this solution?

  * apr-config does not get renamed in 0.9.
  * We introduce a new macro APR_FIND_APR1 to find apr 1.0 by looking
    for apr-1-config.

and similarly for apr-util and friends.  httpd 2.1 changes to use
APR_FIND_APR1 etc. instead of passing an argument to APR_FIND_APR.  If
an app wants to work against both versions of apr, it tries
APR_FIND_APR1 and then tries APR_FIND_APR if apr_found is no.

> (BTW note that the apr-config script is only named apr-N-config by
> "make install"; it's still called "apr-config" in a build tree)

Any reason that can't change?  If it can't change, APR_FIND_APR1 can
use apr-config when using a bundled apr directory.

(Also, since I haven't seen other people jumping up and volunteering
to make this happen, where is the boundary between what you're willing
to do and where I should submit a patch?)


Mime
View raw message