apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] add apr-config
Date Tue, 11 Dec 2001 21:29:07 GMT
On Tue, Dec 11, 2001 at 06:53:42AM -0800, Ryan Bloom wrote:
> On Tuesday 11 December 2001 01:29 am, Justin Erenkrantz wrote:
> > In the style of glib-config, neon-config, and countless others.
> > This greatly eases the burden of parsing APRVARS from external
> > programs.  It is by no means complete, but I can get flood building
> > with this (and removes major headaches for us there).  And, I'm
> > about to try my hand at SVN's configure script.
> >
> > For now, it has access to all of the variables in APRVARS, but
> > doesn't have command line options for each one as I'm not sure
> > what each of these oddball variables do.
> >
> > So, I think this is a good thing.  Comments?  I'll probably
> > commit tomorrow (err, later today) unless someone objects.  -- justin
> Personally, I'm not a big fan of having a library install a binary on the machine
> just to query the build options.  This is why Greg's original idea for this problem
> was to add a function to the library which APR programs could use to 
> retrieve this information.  I would be much happier with that implementation,
> because it removes the possibility that you will update your library, and have
> an out of date apr-config script.

apr-config (and the similar ones in other packages) aren't binaries. They
are simple shell scripts. Note that APRVARS is a shell script, too :-)

Asking about CFLAGS, dependendent libs, etc, cannot be done by APR
functions. How do you compile and link to APR to retrieve that information
if you don't have that info? (chicken and egg)

My comment a while back was only related to versioning. An app can link
against an APR, query its version, and decide to work with APR differently,
punt, or any other number of options.

No.. the apr-config is meant to replace APRVARS. The latter is really awful
in terms of apps trying to use APR. 

* its names have no namespace protection
* you have to "source" the script: it can do *anything* to the target shell
  environment. the caller has zero control.

I must prefer apr-config, where a caller can get just the pieces it needs,
and can do what it wants with them. For example:

MY_CFLAGS="`$(apr_config) --cflags`"

In this case: it has its own name, and it hasn't had its variable space
polluted by APR.

I'm a huge +1 on tossing APRVARS and moving towards apr-config. I also think
that other people will see that, be familiar with its purpose, and will be
able to integrate APR much more easily.


Greg Stein, http://www.lyra.org/

View raw message