Re: generating pc file

[Nick Bowler]

On 2012-09-20 12:05 -0400, David A. Wheeler wrote:
> Russ Allbery:
> > I suppose I should have been clearer.  I believe the method using
> > sed is correct, and generating the file at Autoconf time is not as
> > correct (although it's workable).
> 
> I agree that generating .pc files at "configure" time is the wrong
> time; it should be done at "make" time.
> 
> Regarding "AX_CREATE_PKGCONFIG_INFO", he says:
> > That macro has gotten better (it at least doesn't put the user's
> > CPPFLAGS and LDFLAGS into the *.pc file like it used to), but I
> > still would not recommend people use it...
> 
> I use the "sed" approach, but it's painful to create and maintain.
> Every time you need another variable substitution, you gotta modify
> it.  Since it's not trivial, many people won't do it.  I currently
> recommend that people use AX_CREATE_PKGCONFIG_INFO, because they're
> far more likely to actually do it, and it maintains.
> 
> This is a need for *every* library.  Shouldn't a trivial capability to
> generate replacements, at "make" time, be built into autoconf or
> automake?!?  It might be something that needs coordination between
> them.  Until there is, it seems that AX_CREATE_PKGCONFIG_INFO is the
> best available approach, since it's the closest-available to correct
> that's easy to do.

I wonder if all that's needed is an option to override a configure-
time decision when you run config.status?  Then you could use the
config.status machinery to perform substitutions by calling it at make
time, and not have to maintain your own code that does the same thing.
Then the makefile could have a rule (either automatically provided by
Automake or hand-written by the user) that looks something like:

  libfoo.pc: libfoo.pc.in $(top_builddir)/config.status
        $(SHELL) $(top_builddir)/config.status --file=$@ \
                                   --override prefix=$(prefix)

which behaves exactly as usual except that @prefix@ is replaced with
the make-time expansion of $(prefix) instead of what it normally would
be (obviously the actual command would need an override for each
installation directory variable).

Such a feature could be a bit tricky, though, as it looks like all this
information gets hardcoded into a big giant string in the script.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)